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PREFACE 


0.1 MANUAL OBJECTIVES AND READER ASSUMPTIONS 


This manual is a tutorial, intended to introduce the user to the basic 
concepts and capabilities of the RSX-11D Task Builder. 


Examples are used to introduce and describe features of the Task 
Builder. These examples proceed from the simplest case to the most 
complex. The reader may wish to try out some of the sequences to test 
his understanding of the document. 


The user should be familiar with the basic concepts of the RSX-11D 


system described in the RSX-11D Executive Reference Manual and with 
basic operating procedures described in the RSX-11D User's Guide. 


0.2 STRUCTURE OF THE DOCUMENT 

The manual has seven chapters. The first four chapters describe the 
basic capabilities of the Task Builder. The last three chapters 
describe the advanced capabilities. The Appendices list error 
messages and give detailed descriptions of the structures used by the 
Task Builder. 

Chapter 1 outlines the capabilities of the Task Builder. 


Chapter 2 describes the command sequences used to interact with the 
Task Builder. 


Chapter 3 lists the switches and options. 


Chapter 4 describes memory allocation for the task and for the’ system 
and gives examples of the memory allocation file. 


Chapter 5 describes the overlay capability and the language used _ to 
define an overlay structure. 


Chapter 6 gives the two methods that can be used for loading overlay 
segments. 


Chapter 7 introduces shareable global areas which can be used _ for 
communication between tasks or to reduce the system's memory 
requirements. 


A Glossary of terms is given in Appendix G. 
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0.3 ASSOCIATED DOCUMENTS 


Associated RSX-11D documents are described and their readerships are 
defined in the RSX-11D Documentation Directory, Order Number 
DEC-11-OXUGA-C-D. 


CHAPTER 1 


INTRODUCTION 


This manual introduces the user to the Task Builder and defines’ the 
role of the Task Builder in the RSX-11D System. 


The fundamental executable unit in the RSX-11D System is the task. A 
routine becomes an executable task image, as follows: 


1. The routine is written in a supported source language. 
2. The routine is entered as a text file, through an editor. 


3. The routine is translated to an object module, using’ the 
appropriate language translator. 


4. The object module is converted to a task image using the Task 
Builder. 


5. The task is then installed. 
6. Finally, the task is run. 


If errors are found in the routine as a result of executing the’ task, 
the user edits the text file created in step 2 to correct the errors, 
and then repeats steps 3 through 6. 


If a single routine is to be executed, the user provides the object 
module filename to be used as Task Builder input and a task image 
filename to be assigned to the Task Builder output. 


In typical applications, a collection of routines is run rather than a 
Single program. In this case the user names each of the object module 
files. Then the Task Builder links the object modules, resolves any 
references to any shareable global areas and produces a single task 
image which is ready for installation and execution. 


The Task Builder makes a set of assumptions (defaults) about the task 
image based on typical usage and storage requirements. These 
assumptions can be changed by including switches and options in the 
task-building terminal sequence, thus directing the Task Builder to 
build a task which more closely represents the input/output = and 
storage requirements of the task. 
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The Task Builder also produces, upon request, a memory allocation file 
which gives information about how the task is mapped into memory. The 
user can examine the memory allocation file to determine what support 
routines and storage reservations are included in the task image. A 
cross reference file of global symbols used can be appended to- the 
memory allocation file. 


Further, and also upon request, the Task Builder produces a= symbol 
table file suitable for input to the Task Builder during the build of 
another task. For example, such a procedure is used in binding’ tasks 
to shareable global areas. 


If a reduction in the amount of memory required by the task is 
necessary, the overlay capability can be used to divide the task into 
Overlay segments. Overlaying a task allows it to operate in a smaller 
memory area and thus makes more space available to other tasks in the 
system. 


If the task is configured as an overlay structure (i.e., a 
multi-segment task), overlay segments are loaded using either the 
autoload or manual method. 


The autoload method makes the loading of overlays transparent to_ the 
user and special calls are not required to load the overlay segments 
of the’ task. Loading of the overlay segments is accomplished 
automatically by the Overlay Runtime System according to the structure 
defined by the user at the time the task was built. 


The manual load method requires that specific calls to the Overlay 
Runtime System be included in the coding of the task, and gives the 
user full control over the loading process. 


If the task communicates with another task, or makes use of resident 
Subroutines to save memory, the Task Builder allows the user to link 
to existing shareable global areas and to create new shareable global 
areas for future reference. 


The user can become familiar with the capabilities of the Task Builder 
by degrees. Chapter 2 of this manual gives the basic information 
about Task Builder commands. This information is sufficient to handle 
Many applications. The remaining chapters deal with special features 
and capabilities for handling advanced applications and tailoring the 
task image to suit the application. The appendices give detailed 
information about the structure of the input and output files 
processed by the Task Builder. 


This manual describes the handling of an example application, CALC. 
In the first treatment of CALC, the user builds a task using all the 
default assumptions. Successive treatments illustrate the main points 
of each chapter in a realistic manner. Switches and options are added 
as they are required, an overlay structure is defined when the’ task 
increases in size, the loading of overlays is optimized, and finally a 
shareable global area is added. 


The memory allocation (map) files for the various stages of task 
development are included. The effect of a change can be observed by 
examining the map for the previous example and the map for the example 
in which the change is made. 


CHAPTER 2 


COMMANDS 


2.1 GENERAL COMMAND DISCUSSION 


This chapter describes command sequences that can be used to _ build 
tasks. Each command sequence is’ presented, by example, from the 
simplest case to the most complex. All commands are then summarized 
by a set of syntactic rules. 


The first of a set of examples, designed to illustrate some of the 
important features of the command language, concludes this chapter. 
This example illustrates a simple task building sequence for a typical 
application: 


The convention of underlining system-generated text to distinguish it 
from user type-in is used in this manual. For example: 


TKB>IMG1=IN1 


The underline in the dialogue indicates that the system printed “TKB>’ 
and the user typed “IMG1=IN1’. 


Consider again the creation and execution of a task. Suppose ae user 
writes a FORTRAN program which is entered through a text editor as 
file PROG. Then, the following commands are typed in response to the 
Monitor Console Routine’s reguest for input: 


MCR>FOR CALC=PROG 
CR>TKB IMG=CALC 
CR>INS IMG 
CR>RUN IMG 


| 


= 


| 


= 


= 


The. first command (FOR) causes the FORTRAN compiler to translate’ the 
source language of the file PROG.FTN into a relocatable object module 
in the file CALC.OBJ. The second command (TKB) causes the Task 
Builder to process the file CALC.OBJ to produce the task image file 
IMG.TSK. The third command (INS) causes Install to add the task to 
the directory of executable tasks. Finally, the fourth command (RUN) 
causes the task to execute. 
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The example just given includes the command 
MCR>TKB IMG=CALC 


This command illustrates the simplest use of the Task Builder. It 
gives the name of a single file as output and the name of a single 
file as input. This chapter describes, first by example and then by 
syntactic definition, the complete facility for the specification of 
input and output files to the Task Builder. 


2.1.1 Task Command Line 


The task-command-line contains the output file specifications followed 
by an equal sign and the input file specifications. There can be up 
to three output files and any number of input files. 


The output files must be given in a specific order: the first file 
named is the task image file, the second is the memory allocation 
file, and the third is the symbol definition file. The memory 
allocation file contains information about the size and location of 
components within the task. The symbol definition file contains’ the 
global symbol definitions in the task and their virtual or relocatable 
addresses in a format suitable for re-processing by the Task Builder. 
The Task Builder combines the input files to create ae_e single 
executable task image. 


Any of the output file specifications can be omitted. When all three 
output files are given, the task-command line has the form: 


task-image, mem-allocation, symbol-definition=input, ... 
Consider the following commands and the ways in which the output 
filenames are interpreted. 

Command Output Files 
MCR>TKB IMG1,MP1,SF1=IN1 The task image file is IMG1.TSK, the 


memory allocation file is MP1.MAP, and 
the symbol definition file is SF1.STB. 


MCR>TKB IMG1=IN1 The task image file is IMG1.TSK. 

MCR>TKB ,MP1=IN1 The memory allocation file is MP1.MAP. 

MCR>TKB ,,SF1=IN1 The symbol definition file is SF1.STB. 

MCR>TKB IMG1,,SF1=INI1 The task image file is IMG1.TSK and the 
symbol definition file is SF1.STB. 

MCR>TKB =IN1 This is a diagnostic run with no output 
files. However, any errors encountered 


will produce relevant error message. 
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2.1.2 Multiple Line Input 


Although there can be a maximum of three output files, there can be 
any number of input files. When several input files are used, a more 
flexible format is sometimes necessary, one that consists of several 
lines. This multi-line format is also necessary for the inclusion of 
options, as discussed in the next section. 


If the user types “TKB” alone, the Monitor Console Routine (MCR) 
invokes the Task Builder. The Task Builder then prompts for input 
until it receives a line consisting of only the terminating sequence 


ae se Aaa 
The sequence 


MCR>TKB 
TKB>IMG1,MP1=IN1 
TKB>IN2,IN3 
TKB>// 


produces the same result as the Single line command: 
MCR>TKB IMG1,MP1=IN1,IN2,IN3 


This sequence produces the task image file IMG1.TSK and the memory 
allocation file MP1.MAP from the input files IN1.OBJ, IN2.OBJ, and 
IN3.OBJ. 


The output file specifications and the separator “=” must appear on 
the first TKB command line. Input file specifications can begin or 
continue on subsequent lines. 


The terminating symbol “//’° directs the Task Builder to stop accepting 
input, build the task, and return to the Monitor Console Routine 
level. 


2.1.3 Options 


Options are used to specify the characteristics of the task being 
built. If the user types a single slash ‘/’, the Task Builder 
requests option information by displaying ‘ENTER OPTIONS: and 
prompting for input. 


MCR>TKB 
TKB>IMG1,MP1=IN1 
TKB>IN2,1IN3 


In this sequence the user’ entered the options PRI=199 and 
COMMON=JRNAL:RO and then typed a double slash to end option input. 
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The syntax and interpretation of each RSX-11D Task Builder option are 
given in Chapter 3. 


The general form of an option is a keyword followed by an equal _ sign 
“=” and an argument list. The arguments in the list are separated 
from one another by colons. In the example given, the first option 
consists of the keyword “°PRI” and a single argument ‘190° indicating 
that the task is to be assigned the priority 188. The second option 
consists of the keyword “COMMON” and an argument list “JRNAL:RO’, 
indicating that the task accesses a common region named JRNAL and _ the 
access is read-only. 


More than one option can be given on a line. The symbol exclamation 
point “!° is used to separate options on a single line. For example: 


TKB>PRI=199 ! COMMON=JRNAL: RO 
is equivalent to the two lines 


TKB>PRI=190 
TKB>COMMON=JRNAL: RO 


Some options have argument lists that can be repeated. The symbol 
comma °,° is used to separate the argument lists. For example: 


TKB>COMMON=J RNAL: RO,RFIL: RW 
In this command, the first argument list indicates that the task has 
requested read-only access to the shared region JRNAL. The second 
argument list indicates that the task has requested read-write access 
to the shared region RFIL. 
The following three sequences are equivalent: 
TKB>COMMON=JRNAL:RO,RFIL: RW 
TKB>COMMON=JRNAL:RO ! COMMON=RFIL: RW 


TKB>COMMON=JRNAL : RO 
TKB>COMMON=RFIL: RW 


2.1.4 Multiple Task Specification 


If more than one task is to be built, the terminating symbol, ‘/’ 
(slash), can be used to direct the Task Builder to stop accepting 
input, build the task, and request information for the next’ task 
build. 


Consider the Sequence: 


TKB>IMG1=IN1 
KB>IN2,IN3 
TKB>/ 

ENTER OPTIONS: 


4 
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The Task Builder accepts the output and input file specifications and 
the option input, then stops accepting input when it encounters the 
“/° during option input. The Task Builder builds IMG1.TSK and returns 
to accept more input. 


2.1.5 Indirect Command File Facility 


The sequence of commands to the Task Builder can be entered directly 
or entered as a text file and later invoked through the indirect 
command file facility. 


To use the indirect command file facility, the user first prepares a 
file that contains the user command input for the desired interaction 
with the Task Builder. Then, the contents of the indirect command 
file are invoked by typing “@° followed by the file specification. 


Suppose the text file AFIL is prepared, as follows: 


IMG1,MP1=IN1 
IN2,1N3 

/ 

PRI=100 
COMMON=J RNAL : RO 
// 


Later, the user can type: 
MCR>TKB @AFIL 


When the Task Builder encounters the symbol °@’, it directs its search 
for commands to the file specified following the “@° symbol. When the 
Task Builder is accepting input from an indirect file, it does not 
display prompting messages on the terminal. The 1-line command which 
enables Task Builder to accept commands from the indirect file AFIL is 
equivalent to the keyboard sequence: 


TKB>COMMON=J RNAL : PRO 
TKB>// 


When the Task Builder encounters a double-slash in the indirect file, 
it terminates indirect file processing, builds the task, and exits to 
the monitor upon completion. 
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However, if the Task Builder encounters an end-of-file in the indirect 
file before a double slash, it returns its search for commands to the 
terminal and prompts for input. 


The Task Builder permits three levels of indirection in file 
references. The indirect file referenced in a terminal sequence can 
contain a reference to another indirect file, which in turn references 
the third indirect file. 


Suppose the file BFIL.CMD contains all the standard options that are 
used by a particular group at an installation. That is, every 
programmer in the group uses the options in BFIL.CMD. To include 
these standard options in a task building file, the user modifies AFIL 
to include an indirect file reference to BFIL.CMD as a separate line 
in the option sequence. 


Then the contents of AFIL.CMD are: 


IMG1,MP1=IN1 
IN2,IN3 

i: 

PRI=1090 
COMMON=JRNAL: RO 
@BFIL 


Ff 
Suppose the contents of BFIL.CMD are: 


STACK=109 
UNITS=5 ! ASG=DT1:5 


The terminal equivalent of the command 
MCR>TKB @AFIL 
then is: 


MCR>TKB 

TKB>IMG1 ,MP1=IN1 
TKB>IN2,1IN3 

TKB>/ 

ENTER OPTIONS: 
TKB>PRI=199 
TKB>COMMON=JRNAL : RO 
TKB>STACK=199 
TKBOUNITS=5 ! ASG=DT1:5 
TKB>// 

CR 


| 


s 
Vv 


The indirect file reference must appear as a separate line. For 
example, if AFIL.CMD were modified by adding the “@BFIL’ reference on 
the same line as the “COMMON=JRNAL:RO° option, the substitution would 
not take place and an error would be reported. 
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2.1.6 Comments 


Comment lines can be included at any point in the sequence. A comment 
line begins with a semicolon °;° and is terminated by a carriage 
return. All text on such a line is a comment. Comments can _ be 
included in option lines. In this case, the text between the 
semicolon and the carriage return is a comment. 


Consider the annotation of the file just described; the user adds 
comments to provide more information about the purpose and the status 
of the task. Specifically, some identifying lines are added along 
with notes on the function of the input files and shareable global 
area. Then, a comment on the current status of the task is added at 
the end of the file. The content of the file is as follows: 


TASK 33A 


DATA FROM GROUP E-46 WEEKLY 


4 we we se Ne Ne 


MG1 ,MP1= 
PROCESSING ROUTINES 
IN1 
, STATISTICAL TABLES 
IN2 
; ADDITIONAL CONTROLS 
IN3 
y 
PRI=19090 
CONNOR GREE Re s RATE TABLES 
TASK STILL IN DEVELOPMENT 
// 


2.1.7 File Specification 


Thus far the interaction with the Task Builder has been illustrated in 
terms of filenames. The Task Builder adheres to the standard RSX-11D 
conventions for file specifier. For any file, the user can_ specify 
the device, the user file directory (ufd), the filename, the type, the 
version number, and any number of switches. 


Thus, the file specifier has the form: 


device: [ufd] filename.type;version/sw... 


COMMANDS 


RETURN 
END 
*CL 
EDI>RPRT.FTN 
[EDI -- CREATING NEW FILE] 
INPUT 
SUBROUTINE RPRT 
C INTERIM REPORT PROGRAM 
Cc COMMUNICATION REGION 
COMMON /DTA/ A(20@) ,I 
RETURN 
END 
*EX 
[EDI -- EXIT] 


2.2.2 Compiling the FORTRAN Programs 
The FORTRAN programs are compiled by the following sequence: 


MCR>FOR 

FOR>RDIN, LRDIN=RDIN 
FOR>PROC1 , LPROC1=PROC1 
FOR>RPRT, LRPRT=RPRT 


The first command invokes the FORTRAN compiler. The second command 
directs the compiler to take source input from RDIN.FTN, place the 


relocatable object code in RDIN.OBJ and write the Jlisting in 
LRDIN.LST. The remaining commands perform similar actions for the 


source files PROC] and RPRT. 


2.2.3 Building the Task 
The task image for the three programs is built in the following way: 
MCR>TKB CALC;1,LP:=RDIN,PROC1,RPRT 


The task building command specifies the name of the task image file 
(CALC.TSK;1), the device for the memory allocation file (LP) and the 
names of the input files (RDIN.OBJ, PROC1.OBJ and RPRT.OBJ). The task 
makes use of all the default assumptions for switches and options. 


2.3 SUMMARY OF SYNTAX RULES 


Syntactic rules for the interaction between the user and the Task 
Builder are given here. These rules do not present any new 
information; rather, they define, in a more formal and concise way, 
the syntax of the commands already described in this chapter. 


COMMANDS 
In the syntax rules, the symbol °...° indicates repetition. For 
example, 
input-spec, ... 


means one or more input-spec items separated by commas; that is, one 
of the following forms: 


input-spec 

input-spec, input-spec 

input-spec, input-spec, input-spec 

eee etC. 
As another example, 

ARGS. — ev 
means one or more arg items separated by colons. 
As a final example, 


TKB>input-line 


means one or more of the indicated “TKB input-line’ items. 


2.3.1 Syntax Rules 
The syntax rules are as follows: 


1. A task-building-command can have one of several forms. The 
first form is a single line: 


MCR>TKB task-command-line 
The second form has additional lines for input file names: 


MCR>TKB 
TKB>task-command-line 
TKB>input-line 


TKB>terminating-symbol 
The third form allows the specification of options: 


MCR>TKB 
TKB>task-command-line 
TKB>/ 

ENTER OPTIONS: 
TKB>option-line 


TKB>terminating-symbol 


COMMANDS 


The fourth form has both input lines and option lines: 


MCR>TKB 
TKB>task-command-line 
TKB>input-line 


TKB>/ 


———ae 


ENTER OPTIONS: 

TKB>option-line 

TKB>terminating-symbol 
The terminating symbol can be: 

/ if more than one task is to be built, or 

// if control is to return to the Monitor 

Console Routine or Batch Processor. 

A task-command-line has one of the three forms: 

output-file-list = input-file, ... 

_ input-file, eee 

@indirect-file 
where indirect-file is a file specifier as defined in Rule 7. 
An output-file-list has one of the three forms: 

task-file, mem-allocation-file, symbol-file 

task-file, mem-allocation-file, 

task-file 
where task-file is the file specifier for the task image 
file; mem-allocation-file, is the file specifier for the 
memory allocation file; and symbol-file is the file 
specifier for the symbol definition file. Any of the 
specifiers can be omitted, so that, for example, the form: 

task-file,,symbol-file 
is permitted. 
An input-line has either of the forms: 

input-file, ... 

@indirect-file 
where input-file and indirect-file are file specifiers. 


An option-line has either of the forms: 


option f .«s% 
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COMMANDS 


@indirect-file 


where indirect-file is a file specifier. 


An option has the form: 


keyword 


argument-list, ... 


where the argument-list is 


ALG s s0% 


The syntax for each of the options is given in Chapter 3. 


A file specifier conforms to standard RSX-11D conventions. 
It has the form 


device: [ufd] filename.type;version/sw... 


where everything is optional. The components are defined as 


follows: 


device 


ufd 


filename 


type 


version 


SW 


is the name of the physical device on which the 
volume containing the desired file is mounted. 
The name consists of two ASCII characters 
followed by an optional 1- or 2-digit octal unit 
number; for example, “LP” or “DTl’. 


is the user file directory number consisting of 
two octal numbers each of which is in the range 
of 1 through 377 (octal). These numbers must be 
enclosed in .brackets and separated by a comma, 
and must be in the following format: 


{[group, member] 


For example, member 228 of group 208 would use 
the following entry: 
[208,228) 


is the name of the desired file. The file name 
can be from 1 to 9 alphanumeric characters, for 
example, CALC. 


is the 3-character type identification. Files 
with the same name but a different function are 
distinguished from one another by the file type; 
for example, CALC.TSK and CALC.OBJ. 


is the octal version number of the file in the 
range 1 through 77777 (octal). Various versions 
of the same file are distinguished from each 
other by this number; for example, CALC;1 and 
CALC 32. 


is a switch specification. More than one switch 
can be used, each separated from the previous 


COMMANDS 


one by a ‘/’. The switch is a 2-character 
alphabetic name which identifies the switch 
option. The permissible switch options and 
their syntax are given in Chapter 3. 


The device, the user file directory code, the type, the version, and 
the switch specifications are all optional. 


The following table of default assumptions applies to missing 
components of a file specification: 


device SY®, the system device * 
group the group number currently in effect * 
member the member number currently in effect * 


type task image TSK 
memory allocation MAP 
symbol definition STB 
object module OBJ 
object module library OLB 
overlay description ODL 
indirect command CMD 


version for an input file, the highest-numbered existing 
version. 


for an output file, one greater than the 
highest-numbered existing version. 


switch (the default for each switch is given in Chapter 
36) 


*I£ an explicit device or [ufd] is given, it becomes the default for 
subsequent files separated by commas on the same side of the equal (=) 
sign. 

For example: 


DT1:IMG1 ,MP1=IN1,DF:IN2,IN3 


File Device 
IMG1.TSK DT1l 
MP1.MAP DT1l 
IN] .OBJ SY@ 
IN2.OBJ DFO 
IN3.OBJ DF@ 


CHAPTER 3 


SWITCHES AND OPTIONS 


a 


This chapter describes the ways in which additional directions can be 
given to the Task Builder for the construction of a task image. Much 
of the information in this chapter is quite specialized and refers to 
topics that are described later in the manual. A quick reading of 
this chapter illustrates to the user various methods of modifying the 
task image file. Later, the chapter can be used as a reference for 
practical applications with specific requirements. 


3.1 SWITCHES 
The syntax for a file specifier, as given in Chapter 2, is: 
dev: [ufd] filename.type;version/sw-l/sw-2.../sw-n 


The file specifier concludes with zero or more switches, sw-l, sw-2, 
ose, Sw-n, and the switches are described in the following text. 


When a switch is not given by the user, the Task Builder establishes a 
setting for the switch, called a default assumption. 


A switch is designated by a 2-character switch code. The allowable 
code values are defined by the processor which interprets the code. 
The code is an indication that the switch applies or does not apply. 
For example, if the switch code is CP (checkpointable), then the 
Switch settings recognized are: 


/CP The task is checkpointable. 
/-CP The task is not checkpointable. 
/NOCP The task is not checkpointable. 


The switch codes allowed by the Task Builder are given in alphabetical 
order in Table 3-1. After the alphabetical listing, a more detailed 
description is given for each switch. 


Switches are primarily used to designate the task attributes which are 
recorded in the task image file during task build and in the System 
Task Directory (STD) entry on Install. They are also used to instruct 
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Table 3-1 
Task Builder Switches 


Code Meaning Applies Default 
to File* sciieeiees ihe eherions anal 
'task can be aborted. =| can be aborted. 


Input file consists of concatenated 
object modules. 


Task is checkpointable 


Cross reference to be appended to 
memory allocation file 


Task contains a debugging aid. 
Task can be disabled. 


Task uses the PDP-11/45 floating 
point processor. 


Task can be fixed in memory 
Task image includes a header. 
Input file is a library file. 


Input file contains an overlay 
description. 


Task is a multi-user task 
Task code is position independent. 
Task has privileged access rights. 


Short memory allocation file is 
required 


Memory allocation file is spooled 


Task p-sections are allocated 
sequentially. 


Selective Symbol Search 
Task is accountable 
Task is to be traced. 


Task Builder exits after n 
diagnostics. 


task image file 

symbol definition file 
memory allocation file 
input file 
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TKB to interpret the input file in a special way (e.g., /DA is used 
when the task contains a debugging aid) and to control the listing of 
the memory allocation file (e.g., /SH is used to request the short 
memory allocation file). 


3.1.1 Task Builder Switches 


The switches recognized by the Task Builder are described in this 
section. For each switch, the following information is given: 


® the switch mnemonic, 
e the file(s) to which the switch can be applied. 
e a description of the effect of the switch on the Task 


Builder, and 
e the default assumption made if the switch is not present. 


The switches are given in alphabetical order. 


3.1.1.1 AB (Abortable) 
file: task image 
meaning: The task can be aborted when it is running 


effect: The Task Builder clears the not-abortable flag in the task 
label block flags word. 


default: AB 


3.1.1.2 CC (Concatenated Object Modules) 

file: input 

meaning: The file contains more than one object module. 

effect: The Task Builder includes in the task image all the modules 
in the file. If this switch is negated, the Task Builder 
includes in the task image only the first module in the 
file. 


default: CC 


3.1.1.3 CP (Checkpointable) 
file: task image 
meaning: The task is checkpointable. 


effect: The Task Builder clears the not-checkpointable flag in the 
task label block flags word. 


default: CP 


3.1.1.4 
file: 
meaning: 


default: 


341.1.5 
file: 
meaning: 


effect: 


default: 


Sekt sb 
file: 
meaning: 


effect: 


default: 


3.1.1.7 
file: 
meaning: 


effect: 


default: 


3.1.1.8 


file: 


meaning: 


effect: 


default: 
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CR (Cross Reference) 


memory allocation 


Produce a global cross reference. 


=CR 


DA (Debugging Aid) 


task image or input. 
The task includes a debugging aid. 


The Task Builder performs the special processing described 
in Appendix F. If this switch is applied to the task image 
file, the Task Builder automatically includes the system 
debugging aid SyY:[1l,1]ODT.OBJ in the task image. When the 
/DA switch iS applied to an input file, the Task Builder 
sets up the specified file as a user-written debugging aid. 


~DA 


DS (Disableable) 


task image 
The task can be disabled. 


The Task Builder clears the not - disableable flag in the 
task label flags word. 


DS 


FP (Floating Point) 


task image 
The task uses the PDP11/45 Floating Point Processor. 


The Task Builder allocates 25 words in the task header for 
the floating point save area. 


FP 


FX (Fixable) 


task image 

The task can be fixed in memory. 

The Task Builder clears the non-fixable flag in the task 
label block flags word. Note that a fixed task will not be 
checkpointed even when built as checkpointable. 


—FX 
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3.1.1.9 HD (Header) 


file: 


meaning: 


effect: 


default: 


3.1.1.10 


task image or symbol definition 


A header is to be included in the task image. A description 


for 


using the negation form of this switch (-HD or NOHD) to 


produce a shareable global area is contained in Chapter 7. 


The Task Builder constructs a header in the task image. The 
contents of the header are described in Appendix C.2. 


HD 


LB (Library File) 


This switch has two forms: 


Ls 


26 


Without arguments: LB 


With arguments: LB:mod-1:mod-2...:mod-8 


The interpretation of the switch depends upon the form. 


file: 


meaning: 


effect: 


input 


1. 


Bs 


If the switch is applied without arguments, the input 
file is assumed to be a library file of relocatable 
object modules (created by the Librarian) which are to 
be searched for the resolution of undefined global 
references. 


If the switch is applied with arguments, the input file 
is assumed to bea library file of relocatable object 
modules from which the modules named in the argument 
list are to. be taken for inclusion in the task image. 
The module names are those defined at assembly time by 
the .TITLE directive (or if no .TITLE directive, the 
filename (first 6 characters) when inserted by the 
Librarian). 


If no arguments are specified, the Task Builder searches 
the file to resolve undefined global references and 
extracts from the library for inclusion in the _ task 
image any modules that contain definitions for such 
references. 


If arguments are specified, the Task Builder includes 
only the named modules in the task image. 
NOTE 
If the user wants the Task Builder’ to 


search a library file both to resolve 
global references and to select named 


default: 


3.1.1.11 


file: 


meaning: 


effect: 


default: 


Sete le 2 


meaning: 


effect: 


default: 


3.1.1.13 


file: 
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modules for inclusion in the task image, 
he must name the library file twice: 
once, with the LB switch and no 
arguments to direct the Task Builder’ to 
search the file for undefined global 
references, and a second time with the 
desired modules to direct the Task 
Builder to include those modules in’ the 
task image being built. 


MP (Overlay Description) 
input 


The input file describes an overlay structure for the task. 
Overlay descriptions are discussed in Chapter 5. 


The Task Builder receives all the input file specifications 
from this file and allocates memory as directed by the 
overlay description. 


NOTE 


When an overlay description file is 
specified as the input file for a task, 
it must be the only input file 
specified. The Task Builder does not 
accept any other input files (except 
those defined in the .ODL file). 


MU (Multi-user) 
Multiple versions of the task can run simultaneously. Note 
that only read-write parts of the task will be duplicated in 
memory. 
The multi-user flag is set in the task label block flags word 
and any read-only section of the root segment is aligned on 
a disk block boundary. 


-MU 


PI (Position Independent) 


task image or symbol definition 


meaning: 


effect: 
default: 
3.1.1.14 


file: 


meaning: 


effect: 
default: 
3.1.1.15 
file: 
meaning: 
effect: 
default: 
3.1.1.16 


file: 


meaning: 


effect: 


default: 
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The task contains only position independent code or data. 
Position independent shareable global areas are described in 
Chapter 7. 


The Task Builder sets the Position Independent Code 
attribute flag in the task label block flag word. 


(PIC) 


-PI 


PR (Privileged) 
task image 


The task is privileged with respect to memory access rights. 
The task can access’ the I/O page, and the SCOM data area 
(including node pool) in addition to its own task space. 
Privileged tasks are described in Chapter 4. 


The Task Builder sets the Privileged Attribute flag in 
task label block flag word. 


the 


=PR 


SH (Short Memory Allocation File) 

memory allocation 

The short version of the memory allocation file is produced. 
Chapter 4 describes the memory allocation file and gives a 
short and a long version of a memory allocation file. 


The Task Builder does not produce the ‘File Contents’ 


section of the memory allocation file. 


-SH 


SP (Spool the Memory Allocation File) 
memory allocation 


If spooling is enabled on the system the memory allocation 
file will be spooled to the output device and deleted. 


The memory allocation file is spooled and deleted. 


SP 


3.1.1.17 
file: 


meaning: 


effect: 


default: 


3.1.1.18 


file: 


effect: 


default: 


i gs er Dae Be 


file: 


meaning: 


effect: 


default: 


3.1.1.20 
file: 


meaning: 
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SQ (Sequential) 


task image 

The task image is constructed from the specified program 
sections in the order stated in the TKB command lines. 
Chapter 4 describes the allocation of the task image and 
gives an example which shows the allocation performed under 
the default assumption and the allocation performed when the 
SQ switch is specified. 


The Task Builder does not re-order the program sections 
alphabetically. This switch must not be used for modules 
that rely upon alphabetical p-section allocation. In 
RSX-11D such modules include FORTRAN I/O handling and FCS 


modules from SYSLIB. 


-SQ 


SS (Selective Search) 


The input file is to be used only to define the required 
symbols. 

The Task Builder includes’ only the required symbol 
definitions from the specified file as distinct from all 


global symbols of that file. This switch is useful when the 
input file is an .STB type, because it reduces the size of 
symbol table searches. 


-SS 


TA (Task Accounting) 

task image 

Accounting data for the task is accumulated if this switch 
is specified and the accounting function of the operating 
system is running. 

The Task Builder allocates an extra 1698 (decimal) words in 
the task header for accumulation of accounting data when the 
task is running. 


-TA 


TR (Traceable) 
task image 


The task is traceable. 


effect: 


default: 


3.1.1.21 


file: 


meaning: 


effect: 


default: 


SWITCHES AND OPTIONS 


The Task Builder sets the T bit in the initial PS word 


the task 


- When the task is executed, 


the completion of each instruction. 


-TR 


task image 


XT:n (Exit on Diagnostic) 


More than n error diagnostics are not acceptable. 


The Task 


produced. 


decimal 


nN. 


#n 
If n is 


-XT 


3.1.2 Examples 


Builder 
The 
or octal 


of 
a trace trap occurs on 


exits after n error diagnostics have been 


number of diagnostics can be specified as 
number, using the convention: 


means a decimal number 
or n means an octal number. 


not specified, it is assumed to be l. 


The following terminal sequences illustrate the use of switches 
file specifications and the resulting interpretation. 


Terminal Sequence 


MCR>TKB 


MCR>TKB 


IMG1/CP/DA=IN1/-CC 


TKB>IMG2/PR,MP1/SH= 
TKB>IN2, [1,1] EXEC.STB 


TKB>// 


= 


ck 


IM IV 


TKB 


bree 


B>// 


>IMG3=IN3 
B>LB1/LB: SUB1:SUB2 
B>LB1/LB,DBG1/DA 


Interpretation 


a 


in 


The task IMG1.TSK is checkpointable and 
includes the debugging aid 
SY: [1,1]ODT.OBJ. The input file IN1 


contains only one object module. 


The task IMG2.TSK is a privileged task. 
The short memory allocation file MP1.MAP 


is requested. The inputs for the task 


are the file IN2.OBJ and the symbol 
definition file SY:[1,1] EXEC.STB which 
links the task to the subroutines’~ and 


data base of the Executive. 


The task IMG3.TSK contains the input 
file IN3.0BJ, the modules SUB1 and SUB2 
from the library file LBl, and the 
debugging aid DBG1.OBJ. The library 
file LB1.OLB is specified a second time 
without arguments so that the Task 
Builder will search the file for 


undefined global references. 
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MCR>TKB IMG4/XT: 5=TREE/MP The Task IMG4.TSK is built from _ the 
overlay description contained in the 
file MTREE.ODL. If more than five 
diagnostics occur, the Task Builder 
aborts the run. 


3.1.3 Override Conditions 


In some cases, it is not reasonable to apply two particular switches 
to a file. When such a conflict occurs, the Task Builder selects the 
overriding switch according to the following table: 


Switch switch overriding switch 
Any task -HD -HD 

image switch 

except 

PI and SQ 

CG LB LB 

CP FX -FX 


For example, in the terminal sequence: 


MCR>TKB IMG5=IN6,IN5/LB/CC 


The input file IN5 is assumed to be a library file that is to be 
searched for undefined global references and not an input file with 
several object modules. 


3.2 OPTIONS 


Options are available to the user of the RSX-11D Task Builder’ to 
supply information about the characteristics of the task to the Task 
Builder. 


Some of these options are of interest to all users of the system, some 
are of interest only to the FORTRAN programmer, and some are of 
interest only to the MACRO-11 programmer. The interest range is given 
with the description of the option. 


Options can be divided into seven categories. The identifying 
mnemonics and a brief description for each category are listed below: 


1. contr - Control options affect Task Builder execution. 
ABORT is the only member of this category. The 
user can direct the Task Builder to abort the task 
build by the use of the option ABORT. 
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2. ident ~ Identification options identify task 
characteristics. The task name, priority, user 
identification code, and partition can be 
specified by the use of options in this category. 


3. alloc - Allocation options modify the tasks memory 
allocation. The size of stack, program-sections 
in the task, and FORTRAN work areas and buffers 
can be adjusted by the use of options in this 
category. 


4. share - Storage sharing options indicate the task’s 
intention to access a shareable global area. 


5. device - Device specifying options specify the number of 
units required by the task and the assignment of 
physical devices to logical unit numbers. 


6. alter - Content altering options define a global symbol 
and value or to introduce patches in the task 
image. 

7. synch - Synchronous trap options define synchronous’ trap 
vectors. 


Table 3-2 lists all the options alphabetically. A brief description 
of each option is given and the interest range of the option is 
indicated by the following codes: 


F option is of interest to FORTRAN programmers only. 
M option is of interest to MACRO-11 programmers only. 
FM option is of interest to both. 


The mnemonic for the category to which the option belongs is also 
indicated. in the table. 


The options are then described in more detail by category. 


NOTE 


Many of the TKB options can be 
overridden at install time (See RSX-11D 
Users Guide). 
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Table 3-2 
Task Builder Options 


contr 


Meaning 


ABORT Direct TKB to terminate build. 


alter 


ABSPAT Declare absolute patch values. 


ACTFIL Declare number of files open alloc 


simultaneously. 


ASG Declare device assignment to device 


logical units. 


Define lowest virtual address. alloc 


BASE 


Declare task’s intention to access share 


a shareable global area. 


COMMON 


EXTSCT alloc 


Declare extension of a program section. 


alloc 


EXTTSK Extend task memory allocation at 


install time. 


Declare extension of buffer used alloc 
for processing format strings 


at run-time. 


FMTBUF 


GBLDEF Declare a global symbol definition. 


GBLPAT Declare a series of patch values 


relative to a global symbol. 


Declare task’s intention to access 
a shareable global area. 


LIBR 


Declare an extension to the FORTRAN 
record buffer. 


MAXBUF 


Declare the address and size of 
the debugging aid SST vector. 


ODTV 


PAR Declare partition name and dimensions. 


POOL Declare pool usage limit 


PRI Declare priority. 


Declare the size of the stack. 


STACK 


TASK Declare the name of the task. 


TOP Define highest virtual address. 
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Table 3-2 (Cont.) 
Task Builder Options 


M 


Declare the address of the task 
SST vector. 


synch 


Declare the user identification code FM ident 
under which the task runs. 


Declare the maximum number of units. device 


3.2.1 Control Option 


Only one control option is available. This option is of interest to 
all users of the system. 


3.2.1.1 ABORT (Abort the current Task Build) - The ABORT option 
directs the Task Builder to abort the current task build. 


This option is used when it is discovered that an earlier error in the 

command sequence will cause the Task Builder to produce an unusable 

task image. 

The Task Builder, on recognizing the keyword ABORT, stops accepting 

input, closes all opened files, deletes all output files and restarts 

for another task build. 

An example of the use of the ABORT option is given in section 3.3. 

syntax: ABORT = n 

where n is an integer value. The integer is required to 

satisfy the general form of an option; however, 
the value is ignored in this case. 


default: none 


NOTE 


The use of CTRL Z causes the Task 
Builder to stop accepting input, build 
the task, and then terminate. 


The ABORT option is the only proper’ way 
to restart the Task Builder if an error 
is discovered and the Task Builder 
output is not desired. 
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3.2.2 Identification Options 


Four options are available for specifying task identifying 
information. These options are of interest to all users of the 
system. 


The identification options specify the name of tthe task, the user 
identification code, the priority, and the partition. The user 
identification code can be specified when the task is installed and 
also when it is run. If such a specification is not made, the user 
identification code established when the task was built is used. The 
task runs under the most recently specified UIC. 

3.2.2.1 TASK (Task Name) - The TASK option specifies the task’s name. 
syntax: TASK = task~-name 


where: task-name is a 1- to 6-character radix-5@ name identifying 
the task. 

default: The name of the task image file is used to identify the task 
when the task is installed. This option is used when it is 
desirable to store the task image file under one name, but 


run the task under another name (e.g., MAX.TSK and 
CORMAC.TSK both use the task name ...MAC). 


3.2.2.2 UIC (User Identification Code) - The UIC option declares’ the 
User Identification Code (UIC) for the task if no UIC is specified 
when execution is requested. 
syntax: UIC =[{group,member ] 


where: group is an octal number in the range 1 - 377 which 
specifies the group. 


member is an octal number in the range 1 - 377 which 
specifies the member number. 


default: The UIC specified by the MCR HEL[LO] command. 


3.2.2.3 PRI (Priority) - The PRI option declares the priority at 
which the task executes. If priority is not specified when the task 
is installed, the priority declared in the PRI option is used. 


syntax: PRI = priority-number 
where: priority-number is a decimal integer in the range 1 - 256 


default: 5@(established by Install) 


3.2.2.4 PAR (Partition) - The PAR option identifies the partition in 
which the task is run unless overriden at install or run time. 


syntax: PAR = pname 


where pname is the name of the partition 


default: none (established at install time) 
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3.2.3 Allocation Options 


These options direct the Task Builder to change the length of an 
allocation. The first three options are of interest only to the 
FORTRAN programmer. The remaining options are of interest to all 
users. 


3.2.3.1 ACTFIL (Number of Active Files) - The ACTFIL option declares 


the number of files that the task can have open simultaneously. For 
each active file, an allocation of approximately 512 bytes is made. 


If the number of active files used by a task is less than the default 
assumption of four, the ACTFIL option can be used to save space. If 
the number of active files is more than the default assumption, the 
ACTFIL option must be used to direct the Task Builder to make the 
additional allocation so that the task can run. If a double buffered 
FCS is used, the ACTFIL specification must be doubled also. 


The FORTRAN Object Time System (OTS) and File Control Services (FCS) 
must be included in the task image for the extension to take place. 
The p-section that is extended has the reserved name “S$SFSRI1”°. 


syntax: ACTFIL = file-max 


where: file-max is a decimal integer indicating the maximum number 
of files which can be open at the same time. 


Gefault: ACTFIL = 4 


3.2.3.2 MAXBUF (Maximum Record Buffer Size) - The MAXBUF option 
declares the maximum record buffer size required for all files used by 
the task. 


This option must be used to extend the buffer size whenever a file is 
to be processed in which the maximum record size exceeds the default 
buffer length as specified for the device by the System Manager during 
system generation. 


The FORTRAN Object Time System must be included in the task image for 

the extension to take place. The program section that is extended has 

the reserved name ‘$SIOB1’. 

syntax: MAXBUF = max-record 

where: max-record is a decimal integer, larger than the 
default, which specifies the maximum record 
size in bytes. 


default: MAXBUF = 132 
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3.2.3.3 FMTBUF (Format Buffer Size) - The FMTBUF option declares’ the 
length of internal working storage allocated for the parsing of format 
specifications at run-time. The length of this area must equal or 
exceed the number of bytes in the longest format string to be 
processed. 


Run-time processing occurs whenever an array is referenced as_ the 

source of formatting information within a FORTRAN I/O Statement. The 

program section to be extended has the reserved name “‘SSOBF1’. 

syntax: FMTBUF = max-format 

where: max-format is a decimal integer larger than the default, 
which specifies the number of characters in 
the longest format specification. 


default: FMTBUF = 132 


3.2.3.4 EXTSCT (Program Section Extension) - The EXTSCT option 
declares an extension in size for a p-section. P-sections and their 
attributes are described in Chapter 4. 

If the p-section has the attribute CON (concatenated), the section is 
extended by the specified number of bytes. If the p-section has the 


attribute OVR (overlay), the section is extended only if the length of 
the extension is greater than the length of the p-section. 


For example, suppose that p-section BUFF is 299 bytes long and_ the 
option below is given: 


EXTSCT = BUFF:25@ 


The extension specified for the p-section depends on the CON/OVR 
attribute; specifically: 


for CON the extension is 25@ bytes. 
for OVR the extension is 5@ bytes. 


The extension occurs when the p-section name is encountered in an 
input object file or in the overlay description file. 


syntax: EXTSCT = p-sect-name:extension 


where: p-sect-name is a l- to 6-character radix-5@ name that 
specifies the p-section to be extended. 


extension is an octal integer that specifies the number 
of bytes by which to extend the p-section. 


default: none 
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3.2.3.5 EXTTSK (Extend Task Space) - The read/write space of the task 
may be extended at Install time. 


syntax: EXTTSK = task-extension 


where: task-extension is the decimal number of words by which 
Install extends the upper read/write area of the task. The 
value is rounded up to the next 32-word block boundary. 


default: @ 


This parameter can be overridden by Install option /INC. If the 
EXTTSK option has been overridden, the task must be removed and 
reinstalled without the /INC option to revert back to the EXTTSK 
option. 


This option is used in conjunction with the .LIMIT directive to the 
assembler and the Executive directive Get Task Parameters. 


It is useful in saving disk space that would otherwise be allocated 
for initially empty buffers, for example. Further, the Install /INC 
option provides the ability to vary the size of such buffers. 


3.2.3.6 POOL(Pool Limit) - The POOL option declares the maximum 
number of eight word pool nodes that the task may use simultaneously. 


syntax: POOL = pool —- limit 

where: pool-limit is the decimal number of eight-word nodes in 
the range of 1 through 511. For MU tasks 
this indicates the pool-limit per version. 


default: 4@ 


Example: Set the pool-limit to 60 
POOL=686 


3.2.3.7 STACK (Stack Size) - The STACK option declares the maximum 
Size of the stack required by the task. 


The stack is an area of memory used for temporary storage, subroutine 
calls, and interrupt service linkages. The stack is referenced by 
hardware register R6 (the stack pointer). 

syntax: STACK = stack-size 


where: stack-size is a decimal integer that specifies the 
number of words required for the stack. 


default: STACK = 256 
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3.2.3.8 BASE (Base Address) - The BASE option specifies the base 
address of the task to be at a particular 4K boundary. 


syntax: BASE = bound 


where: bound is a decimal number between @ and 28 which specifies 
the lowest 4K boundary of the image. 


default: @ 


Creation of shareable global area images which are not 
position-independent provides one example of how to use this option. 
In fact, the BASE (and TOP) options are primarily used to _ locate 
shareable global areas, such as libraries and common block, and are 
not recommended for use in building normal tasks. 


Task image addresses are normally allocated upward from zero. This 
type of library file must appear in the same virtual address range of 
each task that shares it. To avoid conflicts with task addresses’ the 
library may be allocated toward the top of the virtual address range 
(i.e., 148088 to 177776) by using a base address declaration (also see 
Section 3.2.3.9) 


NOTE 


The BASE option will override any 
previous TOP specification. 


3.2.3.9 TOP (TOP ADDRESS) - The TOP option declares the ending 
address of a task to be within a 4K boundary. 


syntax: TOP=bound 


where: bound is a decimal number between @ and 28 which specifies 
the highest 4K boundary of the image. 


default: none 
The purpose of this option is the same as the purpose of the BASE 
option except it allows defintion of the last 4K boundary, rather than 
the first 4K boundary. 

NOTE 


The TOP option will override any 
previous BASE specification. 


3.2.3.18 Examples of Allocation Options - If the FORTRAN routines 
contained in file GRP1l use eight files simultaneously and the maximum 


record length in one of these files is 16@ characters, the following 
terminal sequence can be used to build the task: 


MCR>TKB 
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TKB>IMG1 ,MP1=GRP1 
TKB>/ 

ENTER OPTIONS: 
TKB>ACTFIL = 8 
TKB>MAXBUF = 169 
TKB>// 


3.2.4 Storage Sharing Options 


Two options indicate the task’s intention to access a shareable global 
area. These options are of interest to all users of the system. 


By convention, the COMMON option indicates the use of a shareable 
global area that contains only data and the LIBR option indicates the 
use of a shareable global area that contains only code. The two 
options have the same effect, except that when all tasks accessing a 
common area have exited, the area is written back to its file on disk. 
For a library file, the memory allocated to it is simply released. 


3.2.4.1 COMMON (Sharable Common Block) - The COMMON option declares a 
common block for use by the task. 


syntax: COMMON = common-name:access-code[:apr] 


where: common-name is the l- to 6-character radix-58 name of the 
common block. 


access-—code is either RW (read/write) or RO (read-only) 
to indicate the type of access required for 
the task. 

apr is an integer in the range of 1 to 7 which 


specifies the first Addressing Page Register 
to be reserved for the common block. The apr 
is optional. 


default: none 


3.2.4.2 LIBR (Sharable Library) - The LIBR option declares a sharable 
library for use by the task. 


syntax: LIBR = library-name:access-code[:apr] 


where: library-name is the l- to 6-character radix-58 name which 
specifies the library. 


access-code is either RW (read/write) or RO (read-only) 
to indicate the type of access required for 
the task. 

apr is an integer in the range of 1 to 7 which 
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specifies the first Addressing Page Register 
to be reserved for the library. The apr is 
optional. 


default: none 


3.2.4.3 Example of Storage Sharing Options - If the task composed of 


the MACRO-11l programs TST1 and TST2 accesses a shareable common area 
DTST that contains data and a shareable library area STST_ that 
contains code, the following terminal sequence can be used to build 
the task: 


MCR>TKB 
TKB>CHK,LP:=TST1,TST2 
TKB>/ 

ENTER OPTIONS: 
TKB>COMMON = DTST:RW 
TKB>LIBR = STST:RO 
TKB>// 


3.2.5 Device Specifying Options 


The two options in this category are of interest to all system users. 
The UNITS option declares the number of input/output units that the 
task uses. The ASG option declares the devices that are assigned to 
these units. 


The number of logical units and the highest unit number assigned must 
be compatible. An attempt to assign a physical device to a unit 
number that is larger than the total number of units declared is an 
error. Similarly, the number of units declared cannot be less than 
the highest unit assigned. 


Since the options are processed as they are encountered, to increase 
the number of units and assign devices to these units, the user should 
enter the UNITS option first and then the ASG option. Entering the 
options in the reverse order can produce an error message. 


3.2.5.1 UNITS (Logical Unit Usage) ~ The UNITS option declares’ the 
number of logical units that are used by the task. 


syntax: UNITS = max-units 


where: max-units is a decimal integer in the range of @ to 255 
which specifies the maximum number of logical 
units. 


default: UNITS = 6 
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3.2.5.2 ASG (Device Assignment) - The ASG option declares the 
physical device that is assigned to one or more units. 


syntax: ASG = device-name:unit-num-l:unit-num-2:...:unit-num-8 
where: device-name - is a 2-character alphabetic device name 
followed by a l- or 2-digit decimal unit 
number. 
unit-num-1 are decimal integers indicating the 
unit-num-2 logical unit numbers. 


unit=num-8 


default: ASG = SY@:1:2:3:4, TI@:5, CLO:6 


3.2.5.3 Example of Device Specifying Options - Suppose the FORTRAN 
programs specified in the file GRP1l require nine logical units. The 
device assignments for units 1-6 agree with the default assumptions 
and logical units 7,8 and 9 are assigned to DECtape 1 (DT1). The 
command seguence of the example shown in Section 3.2.3.7 is changed to 
include device assignment options, as follows: 


MCR>TKB 

TKB>IMG1 ,MP1=GRP1 

TKB>/ 

ENTER OPTIONS: 

TKB>ACTFIL = 8 ! MAXBUF = 160 
TKB>UNITS=9 ! ASG = DT1:7:8: 
TKB>// 


3.2.6 Storage Altering Options 
These options alter the task image and are of interest only to. the 
MACRO-11 programmer. The GBLDEF option declares a global symbol and 


value. The options ABSPAT and GBLPAT introduce patches into the task 
image. 


3.2.6.1 GBLDEF (Global Symbol Definition) - The GBLDEF option 
declares the definition of a global symbol. 


The symbol definition is considered absolute. 
syntax: GBLDEF = symbol-name:symbol-value — 


where: symbol-name is a 1 to 6-character radix-5@ name of the 
defined symbol. 


symbol-value is an octal number in the range of 9 to 177777 
which is assigned to the defined symbol. 


default: none 
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3.2.6.2 ABSPAT (Absolute Patch) - The ABSPAT option declares a series 
of patches starting at the specified base address. Up to 8 patch 
values can be given. 


syntax: ABSPAT = seg-name:address:val-l:val-2:...:val-8 
where: seg-name is the l- to 6-character radix-59 name of the 
segment. 
address is the octal address of the first patch. The 


address may be on a byte boundary; however, 
two bytes are always modified for each patch. 


val-1l is an octal number in the range of 9 to 177777 
to be assigned to address. 


val-2 is an octal number in the range of 9 to 177777 
to be assigned to address+2 


val-8 is an octal number in the range of @ to 177777 
to be assigned to address+16(octal).. 


NOTE 


All patches must be within the segment 
memory limits or a fatal error is 
generated. 


3.2.6.3 GBLPAT (Global Relative Patch) - The GBLPAT option declares a 


series of patch values starting at an offset relative to a global 
symbol. Up to 8 patch values can be given. 


syntax: GBLPAT=seg—name: sym-name [+/-offset] :val-l:val-2:...:val-8 


where: sym-name is a 1 to 6-character radix-5@ name which 
specifies the global symbol. 


offset is an octal number used to specify the offset 
from the global symbol. 


seg-name are identical to that defined for ABSPAT 
val-l 
val-2 


val-8 


default: none 
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NOTE 


All patches must be within the segment 
address limits or a fatal error is 
generated. 


3.2.6.4 Example of Storage Altering Options - Suppose that in the 
example composed of the MACRO-11 programs TST1 and TST2, GAMMA is a 


referenced symbol whose value is to be specified when the task is 
built. The user defines the symbol GAMMA to have the value 25 and 
introduces 19 patch values relative to the global symbol DELTA. 


The terminal sequence of example shown in Section 3.2.4.3 is modified 
to include the options GBLPAT and GBLDEF as follows: 


MCR>TKB 

TKB>CHK, LP:=TST1,TST2 

TKB> / 

ENTER OPTIONS: 

TKB>COMMON=DTST:RW:5, STST:RO 
TKB>GBLDEF=GAMMA: 25 

TKB>GBLPAT=TST1 :DELTA:1:5:10:15:20:25:380:35 
TKB>GBLPAT=TST1 :DELTA+2@: 40:45 

TKB>// 


3.2.7 Synchronous Trap Options 


Two options are available to declare that the specified vector address 
is to be preloaded into the task header, thus enabling the task to 
receive control on the occurrence of synchronous traps. These options 
are of interest only to the MACRO-11 programmer. 


3.2.7.1 ODTV (ODT SST Vector) - The ODTV option declares a global 
symbol to be the address of the ODT Synchronous System Trap vector. 
The defined global symbol must exist in the part of the task that is 
always in memory. 


syntax: ODTV = symbol-name:vector-length 


where: symbol-name is a l- to 6-character radix-5@ name of a 
global symbol. 


vector-length is a decimal integer in the range of 1 to 32 
which specifies the length of the SST vector 
in words. 


default: none 
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3.2.7.2 TSKV (Task SST Vector) - The TSKV option declares a global 
symbol to be the address of the task SST vector. The defined symbol 
must exist in the part of the task that is always in memory. 


syntax: TSKV = symbol-name:vector-length 
where: symbol-name are as defined for ODTV 
vector-length 


default: none 


3.3 EXAMPLE: CALC;2 


Suppose that in the first execution of the task CALC several logical 
errors are found. The user corrects the program and is now ready to 
make the changes in the program and some adjustments in the task image 
file based on the information he obtained about the size of the task 
in the first task build. 


In this example, he modifies the text file for the program, recompiles 
the program, and rebuilds the task so that only one active file buffer 
is reserve. 


3.3.1 Correcting the Errors in Program Logic 
The FORTRAN source language for the program “RDIN’ is corrected to be: 


READ AND ANALYZE INPUT DATA 
SELECT A PROCESSING ROUTINE 


ESTABLISH COMMON DATA BASE 


COMMON /DTA/ A(288), I 
READ IN RAW DATA 

READ (6,1) A 

al FORMAT (200 F6.2) 

CALL PROC1 


CALL RD1 


QO AAQAANDM 


CALL RPRT 

END 

SUBROUTINE RD1 
RETURN 

END 


Next, the program “RDIN’ is recompiled: 


MCR>FOR RDIN,LRDIN=RDIN 
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Observe that the corrections to “RDIN’ included the addition of a 
subroutine “RD1’. The object file produced by the FORTRAN compiler as 
a result of the above terminal sequence now contains two object 
modules. 


3.3.2 Building the Task 


The user knows from the program logic that only one file is open at a 
time, but the Task Builder assumes that four files are open 
simultaneously. Therefore, the user can utilize the ACTFIL option to 
reduce the space required for the task. 


The task is built with the following terminal sequence: 


MCR>TKB 
TKB>CALC;2,=RDIN,RPRT, PROC] 
TKB>/ 

ENTER OPTIONS: 
TKB>PAR=PAR14K 

TKB>ABORT=1 


TKB -- *FATAL* - ABORTED VIA REQUEST 
ABORT=1 
TKB>CALC;2,LP:/SH=RDIN,PROC1,RPRT 
TKB>/ 


ENTER OPTIONS: 
TKB>PAR=PAR1 4K 
TKB>ACTFIL=1 
TKB>// 


The user introduced the ABORT option to end the task build when he 
realized that he had omitted the memory allocation file. 


The effect of these options on the memory allocation is seen in the 
next chapter. After the description of the task and memory allocation 
files, the memory allocation files for the first two examples are 
given. 


CHAPTER 4 


MEMORY ALLOCATION 


This chapter describes the allocation of task and system memory. The 
Memory allocation file and the cross reference file are described in 
detail and examples of memory allocation files are illustrated. The 


memory allocation file for the example CALC;1 of Chapter 2 and CALC;2 
of Chapter 3 are included and discussed. The effect of the options 
used in CALC;2 can be observed by comparing the two memory allocation 
files. 


4.1 TASK MEMORY 


Task memory in RSX-11D consists of a header, stack, and a set of named 
areas called program section (p-sections). Each p-section has 
associated with it attributes from which the Task Builder can 
determine its base and length. 


Task memory for a single segment task can be represented by _ the 
following diagram: 


Real Memory 
32-Word Boundary 


ZZ vers space LZ. 


p-section 


lca ineatinatientinieatentetinetatatat R/O 

cee Task 
-------—---------- Code and Data 
p-section 


Zz sors space LZ. 


p-section 


ar ae eee Ra ae R/W 
see Task 
Ne a ee ee Code and Data 
p-section 


poe 
impure area 
pointers 
directive status 
word 
task header 


Task Memory for a Single 
Segment Task 


Task Virtual 
4K Boundary 


Real Memory 
32-Word Boundary 


Real Memory 


Task Virtual 
‘as irtual 9 32-Word Boundary 


Real Memory 
32-Word Boundary 


MEMORY ALLOCATION 
4.1.1 Task Header 


The task header contains task parameters and data required by the 
executive for controlling execution of a task. It also provides an 
area for saving the task's contents when a switch is made to another 
task and for accumulating accounting information about the task. It 
is resident at all times when the task is resident, but is not a part 
of the task's virtual address space. A detailed description of the 
header can be found in Appendix C.2. 


4.1.2 Directive Status Word 


Virtual location zero of every RSX-11D task is a reserved word for the 
executive to report the status of all executive directives issued by 
the task. 


4.1.3 Impure Area Pointers 


The words following the directive status word are used as pointers’ to 
the following areas of the task. 


Address Use 
2 Address of FCS data storage area 
4 Address of FORTRAN-OTS work area 
6 Address of overlay run time system work area 


Like the directive status word these parameters occupy the low address 
end of the task stack. 


4.1.4 Stack 


A default stack of 256(decimal) words is allocated for each task. The 
STACK=option may be used to override this allocation. A STACK=0O 
specification is useful in building shareable global areas which do 
not require a stack. (libraries use the task stack space because they 
are within the address space of the binding task). 


4.1.5 R/W Task Code(and Data) 


The R/W p-sections of a task are concatenated to the end of the stack. 
The memory allocation is rounded up to a 32(decimal) word boundary by 
the addition of dead space. 
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4.1.6 R/O Task Code (and Data) 


If there are p-sections in the task which have the read-only attribute 
(read/write is the default), the Task Builder concatenates these and 
allocates them so they occupy an integral number of 32(decimal) word 
blocks. The task will be mapped so that the R-O p-sections will begin 
at the next 4K virtual address. Further, if the task is multi-user, 
these R-O areas will begin on the next available disk block to 
facilitate separate loading of R/W and R-O portions of the task at run 
time. This enables multiple copies of such tasks to share one copy of 
the read-only code (and/or data). The executive treats these shared 
read-only areas of a task much as it treats shareable global areas. 


Note that ODT cannot be used to modify read-only parts of a task. 
This also means that breakpoints cannot be set in such code. Any 
attempt to use ODT in the read-only areas of a task will cause the 
task to terminate with a segment fault. 


4.1.7 P-Sections 


A program section, or p-section, is the basic unit of memory for’ the 
task. A source language program is translated into an object module 
consisting of p-sections. For example, the object module produced by 
compiling a typical FORTRAN program consists of a p-section containing 
the code generated by the compiler, a p-section for each common block 
defined in the FORTRAN program, and a set of p-sections reguired by 
the FORTRAN Object Time System. 


A name and a set of attributes are associated with each p-section. 
The p-section attributes are given in Table 4-1. 


The scope-code and type-code are only meaningful when an overlay 
structure is defined for the task. The scope-code is described in 
connection with the resolution of p-section in Chapter 5. The 
type-code is described in connection with the generation of autoload 
vectors in Chapter 6. The memory-code is not used by the _ Task 
Builder. 


The access-code and alloc-code are used by the Task Builder’ to 
determine the placement and the size of the p-section in task memory. 


The Task Builder divides storage into read/write and read-only memory 
and places the p-sections in the appropriate area according to 
access-code. 


The alloc-code is used to determine the starting address and length of 
p-sections with the same name. If the alloc-code indicates that 
p-sections with the same name are to be overlaid, the Task Builder 
places each reference at the same position in task memory and 
determines the total allocation from the length of the longest 
reference, If the alloc-code indicates that p-sections with the same 
name are to be concatenated, the Task Builder places each reference 
one after another in task memory and determines the total allocation 
from the sum of the lengths of the each reference. 


When a p-section has the concatenate attribute, all references to that 
p-section are placed one after another in task memory. If any of 
these references ends on a byte boundary, the next reference to that 
p-section is not word-aligned. 


Attribute 


access-code 


type-code** 


scope-code 


alloc-code 


reloc-code 


memor y-code*** 


LCL* 


CON* 


OVR 


REL* 


ABS 


HIGH 


LOW* 
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Table 4-1 
P-Section Attributes 


Meaning 


(read/write). Data can be read from and 
written into the p-section. 


(read-only). Data can be read from, but 
cannot be written into the p-section. 


(data). The p-section contains data. 


(instruction). The p-section contains 
instructions. 


(global). The p-section name is considered 
across segment boundaries. The Task Builder 
allocates storage for the p-section from 
references outside the defining segment. 


(local). The p-section name is considered 
only within the defining segment. The Task 
Builder allocates storage for the p-section 
from references within the defining segment 
only. 


(concatenate). P-sections with the same name 
are concatenated. The total allocation is 
the sum of the individual allocations. 


(overlay). P-sections with the same name 
overlay each other. The total allocation is 
the length of the longest individual 
allocation. 


(relocatable). Storage in the p-section is 
allocated relative to the virtual base 
address of the partition. 


(absolute). Storage in the p-section is 
always allocated relative to zero. 


(high). The p-section is to be loaded into 
high speed memory. 


(low). The p-Section is to be loaded into 
core. 


* Indicates the default attribute 


== Not to be confused with the I and D space hardware on the PDP 


11/45. 


***k Not implemented 
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4.1.8 Allocation of P-sections 
Suppose the user enters the following command: 
MCR>TKB IMG] ,MP1=IN1,IN2,IN3,LBR1/LB 


The user is directing the Task Builder to build a task image file, 
IMG1.TSK, and a memory allocation file, MP1.MAP, from the input files 
IN1.OBJ, IN2.OBJ, and IN3.OBJ, and to search the library file LBR1.OLB 
for any undefined global references. Suppose the input files are 
composed of p-sections with the following access-codes, alloc-codes, 
and sizes: 


File-name P-section Access Alloc Size 
name Code Code (octal) 


IN1 


First, the Task Builder collects all p-sections with the same name to 
determine the allocation for each uniquely named p-section. 


In this example, there are two occurrences of the p-section named B 
with attributes RW and CON. The total allocation for B is the sum of 


the lengths of each reference; that is, 100 + 120 = 220. The 
allocation for each uniquely named p-section then is: 


P-section Total 
Name Allocation 


- 
Cc 
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The Task Builder then re-organizes the p-sections alphabetically 
places them in memory according to their access-code, as follows: 


C (220) | read only 

B (220) 
read/write 

A (300) 
aes 
ae 


and 


task memory 


4.1.8.1 Sequential Allocation of P-sections - The SQ (sequential) 
Switch affects only the placement of p-sections in task memory. 


P-sections with the same name and attributes are collected as 
described; then uniquely named p-sections are placed in memory in the 
order of input sequence according to the access-code. 


Suppose the user adds the SQ switch to the previous example: 
MCR>TKB IMG1/SQ,MP1=IN1,IN2,IN3,LBR1/LB 


The Task Builder collects the p-sections and places them in memory in 
the input sequence, as follows: 


read only 


A (369) 


read/write 
task memory 


| IL 
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4.1.9 The Resolution of Global Symbols 
When creating the task image file, the Task Builder resolves’ global 


references. Suppose the global symbols are defined and referenced in 
the p-sections in the following way: 


File P-section Global Global 
Name Name Defn. Ref. 


In processing the first file, IN1, the Task Builder finds definitions 
for Bl and B2 and references to Al,Ll1,Cl, and XXX. Since no 
definition exists for these references, the Task Builder defers’ the 
resolution of these global symbols. In processing the next file, IN2, 
the Task Builder finds a definition for Al, which resolves’ the 
previous reference, and a reference to B2, which can be immediately 
resolved. 


When all the input object files have been processed, the Task Builder 
has three unresolved global references, namely: Cl, Ll, and XXX. A 
search of the library file LBR1 resolves Ll and the Task Builder 
includes the defining module in the task image. A search of the 
System Library resolves XXX. The global symbol Cl remains unresolved 
and is, therefore, listed as an undefined global symbol. 


The relocatable global symbol Bl is defined twice and is listed as a 
multiply-defined global symbol on the terminal. The first definition 
of a multiply defined symbol is used by the Task Builder. An absolute 
global symbol can be defined more than once without being listed as 
multiply defined as long as each occurrence of the symbol has the same 
value. The results of these resolutions can be obtained in Figure 
4-1. 
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4.2 SYSTEM MEMORY 
In RSX-11D, system memory consists of the resident executive and a set 


of named areas which are defined at system generation time. These 
named areas are partitions, each of which has parameters of base and 


length. 


A typical system memory layout can be represented by the _ following 


diagram: 
external page 
| paretetonn | 


User Defined 


Partitions 
partition 1 
system common 
All Boundaries subroutines Sebi 
Are 3219) Word - 
Aligned system communications 
region 
system tables, lists 
Permanently 
Resident 
node pool RSX~11D 
System 
executive code 
___ Kernel 
Virtual @ 


bootstrap 


Typical System Memory Layout 


Real 6 — 


4.2.1 Privileged Tasks 


A privileged task has special memory access rights. A _  non-privileged 
task can access only itS own partition and any referenced shareable 
global areas, but a privileged task can, in addition, access SCOM and 
the external page. 


The following diagram illustrates typical privileged and 
non-privileged tasks. Note that APR boundaries are aligned at 4K 
virtual addresses and 32(decimal) word real addresses when in memory. 
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Task Mapping 


4.3 TASK IMAGE FILE 


In addition to the task memory, or core image, the task image file 
contains a label block group. The label block group contains data 
that is used by the Install processor to create an entry in the system 
task directory for the task. The label is described in detail in 
Appendix C, as is the task image file structure. 


4.4 MEMORY ALLOCATION FILE 


The memory allocation file lists information about the allocation of 
task memory and the resolution of global symbols. Figure 4-1 is a 
listing of the memory allocation file produced by example IMG1 of 


Section 4.1. 
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FILE IMG1.TSK;1 MEMORY ALLOCATION MAP 
THIS ALLOCATION WAS DONE ON 13-FEB-75 
AT 15:48 BY TASK BUILDER VERSION R869 


*** ROOT SEGMENT: IN1 


R/W MEM LIMITS: 998900 991577 9816090 
R-O MEM LIMITS: 920099 020277 98083990 
STACK LIMITS: 8990998 800777 881000 
DISK BLK LIMITS: 8900993 980095 999003 
IDENTIFICATION : 

PRG XFR ADDRESS: 801300 

TASK ATTRIBUTES: FP.NF 


PROGRAM SECTION ALLOCATION SYNOPSIS: 


<. BLK.>: 891908 981900 B20B00 


<A >: 8918008 9891277 2900300 
<B >: 081300 091517 B9H220 
<C >: O@200800 0290217 BHHHDB 


<. ABS.>: BBODOH BABHHH OHHHBD 


*** €6FILE: IN1.OBJ;1 TITLE: IN1 IDENT: 
<. ABS.>: 980890 BDOBHDH BDOHDDD 


>>>>>>>>>>>> UNDEFINED REFERENCE: Cl 


<A >: 9918060 801277 890380 

<B >: 0913890 081377 B8OG100 
Bl 0613090-R B2 G@01302-R 

<c >: 920008 820147 8808150 

Figure 4-1 


Memory Allocation File for IMG1.TSK 
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**k* FILE: IN2.OBJ;1 TITLE: IN2 IDENT: 


<A >: 88016808 081247 880258 
Al 991900-R 

<B >: 0814808 081517 689120 
Bl 891306-R 


*** FILE: IN3.OBJ;2 TITLE: IN3 IDENT: 


<C >: 020158 828217 88600508 


*** FILE: SYSLIB.OLB;1 TITLE: MODN IDENT: 
<. ABS.>: OBOBHHD BDHOBHOD BOOUBD 


XXX G890B05 


*** FILE: LBR1.OLB;1 TITLE: LIB1 IDENT: 
<. ABS.>: OB009H BBHBBG BHHDOD 


Ll GOBB22 


REEKKKKKKKEKE 


UNDEFINED REFERENCES: 


Cl 


Figure 4-1 (Cont.) 
Memory Allocation File for IMG1.TSK 


MEMORY ALLOCATION 


4.4.1 Structure of the Memory Allocation File 


The structure of the memory allocation file can be described as 


follows: 


1. 


The memory allocation file consists of the following sequence 
of items: 


heading 

segment description 

program section allocation synopsis 
file contents description 

undefined references summary 


These items are defined in 2 through 6. 


The heading gives the name of the task, date and time of the 
task-build, and the version number of the Task Builder in the 
following form: 


FILE task-image-file-name MEMORY ALLOCATION MAP 
THIS ALLOCATION WAS DONE ON date 
AT time BY TASK BUILDER VERSION version-no. 


The segment description consists of the following sequence of 
items: 
***SEGMENT: segment—name 


R/W MEM LIMITS: start~-addr end-addr length 
R-O MEM LIMITS: start-addr end-addr length 


STACK LIMITS: start-addr end-addr length 
DISK BLK LIMITS: start-blk end-blk blk—length 
IDENTIFICATION: name 


ODT XFR ADDRESS: address 
PRG XFR ADDRESS: address 
TASK ATTRIBUTES: attr-l ... attr-n 


Any line in the seguence is omitted if it does not apply to a 
given task image. 


The constructs in this sequence are defined in Rule 7. 
The program section allocation synopsis has the form: 


p-sect-name-l start-addr end-addr length 


eee 


If the SQ switch is applied, the p-sect-names are listed in 
input order; otherwise p-sect-names are listed in 
alphabetical order. Since p-sections are allocated according 
to their access-code, the alphabetical listing is not 
necessarily sequential. 


The file contents description contains an entry for each 
input file in the form: 
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*K*KFILE filename TITLE title~name IDENT ident-name 


Ke ABS.> 


>>>>> 
<p-sect-—name-1> 


<. BLK.> 


Start-addr end-addr length 

g-name-l value g-name-2 value... 
UNDEFINED REFERENCE g-name-n 
Start-addr end-addr length... 
g-name-1l value-R g-name-2 value-R... 
Start-addr end-addr length 

g-name-l value g-name-2 value 


The absolute global symbols are listed in the p-section named 
- ABS, which is collated first. The blank p-section . BLK. 
is collated last in the listing. 


The undefined references summary has the form: 


KKKEK KKK KKK ERE KK AEKKEKEKREE 
UNDEFINED REFERENCES 


g-name-l 


The remaining constructs are defined as follows: 


segment-name 


start-addr 


end-addr 


length 


start-blk 


end-blk 


blk-length 


address 


name 


attr 


is the name of the segment. 


is the first storage address in octal 
byte format. 


is the last storage address in octal 
byte format. 


is the number of (in octal) bytes 
occupied. 


is the relative block number (in octal) 
for the starting disk location. 


is the last relative block number for 
the disk allocation. 


is the number (in octal) of blocks 
occupied. 


is a byte address (in octal). 


is the name attached to the first 
non-blank .IDENT entry encountered. 


is an attribute code that applies to the 
task image. The list of codes printed 
is: 

NC Task is not checkpointable 


FP Task uses PDP-11/45 floating 
point processor 
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DA Task includes’ the standard 
debugging aid SY0: [1,1]ODT.OBJ 


PI Task contains only position 
independent code and data 


PR Task is privileged 
TR Task initial PS word has T-bit 
enabled 

NH Task does not contain a header 

NF Task is not fixble 

NA Task is not abortable 

ND Task cannot be disabled 

MU Task is multi-user 

TA Task is accountable 
p-sect~—name is the name of a p-section. 
file-name is the name of the file from which the input 


module was taken. 


title-name is the name of the first non-blank .TITLE 
encountered. 


ident-name is the name of the first non-blank .IDENT 
encountered. 


g-name is the name of a global symbol. 


4.4.2 Structure of the Cross Reference Listing 


The cross reference output has two parts: a page header and the 
actual cross reference listing. 


1. The cross reference page header consists of the following 
items: 


name of the map file 
time the map file was created 
cross reference page number 


2. The actual cross reference contains an alphabetic listing of 
each global symbol, its value, and the name of each module 
referring to it. The name of each module is prefixed with a 
character indicating the symbol resolution within the module. 
The cross reference listing has the following format: 


symbol name value (-R) x module-1l x module-2 ... 
x module-n 
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The suffix -R is appended to value if the symbol is 
relocatable. 


Module name prefix characters have the following meaning: 
Prefix Character Reference Type 
blank Module contains a reference that is 
resolved in the same segment or in 


a segment toward the root, or in a 
segment away from the root or ina 


co-~tree. 

@ Module contains a reference that is 
resolved through an autoload 
vector. 

# Module contains a definition that 


is not autoloadable. 


* Module contains an autoloadable 
Gefinition. 


The reader should consult Chapter 5 and the glossary for a discussion 
of unfamiliar terms. 


4.5 EXAMPLES - TWO VERSIONS OF CALC 


The first run of CALC discussed in Chapter 2 produced the memory 
allocation file listed in Figure 4-2 and the short form of the memory 
allocation file obtained for version 2 is shown in Figure 4-3. 


4.5.1 Segment Description 


The memory allocation file heading is self-explanatory. The segment 
description indicates that the task consists entirely of R/W p-section 
and that the task is 43240 (octal) bytes in length. The stack size is 
defaulted to the lower 1000(octal) bytes of the task. 


The program transfer address indicates that task execution begins at 
virtual address 1000. The default attributes assigned to the task are 
floating point (FP) and not fixable (NF). 
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The discussion of the label block in Appendix C explains why the task 
occupies virtual blocks 3 through 46 (octal). 


4.5.2 Program Section Allocation Synopsis 


The blank program section °. BLK.” contains the object code produced 
from the translation of the modules for CALC;1. The code begins at 
virtual address 1999, ends at virtual address 32507, and occupies 
31519 bytes. 


The program section “DTA ° is the memory allocation reserved for the 
common block DTA. 


The remaining program sections are storage regions required by the 
FORTRAN object time system (OTS) and File Control Services (FCS), 
which were called in by the FORTRAN compiler to perform services’ for 
the FORTRAN program. 


4.5.3 File Contents Description 


The file contents description lists for each file the program sections 
that the file contributed to the segment. In CALC;1l there are three 
input files, RDIN.OBJ, PROC1.OBJ, and RPRT.OBJ. In addition to these 
files, the library file SYSLIB.OLB contributed the FORTRAN run-time 
routines and all FCS routines required. 


The input file RDIN.OBJ contains two p-sections; namely, °.BLK.°, and 
‘DTA °. If the program had used a blank or unnamed common, the 


p-section .$$$$. would have appeared in the p-section allocation 
synopsis. The p-section - BLK. contains the code for RDIN.OBJ, 


starts at virtual address 10908, and occupies 15@ bytes. “DTA ~° is 
the p-section containing the common block DTA. This section starts at 
virtual address 32519, and occupies 1442 bytes. 


The input file, PROC1.OBJ, also contains two p-sections; namely, 
“. BLK. , and ‘DTA °”. The p-section °.BLK.”° contains the code for 
PROCI1 and the definition for global symbol “PROC1’, the name of the 


subroutine. 


The memory allocation file reproduced below does not contain the 
modules contributed by the library file SYSLIB.OLB. 
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FILE CALC.TSK;1 MEMORY ALLOCATION MAP 
THIS ALLOCATION WAS DONE ON 13-FEB-75 
AT 14:21 BY TASK BUILDER VERSION R89 


*** ROOT SEGMENT: RDIN 


R/W MEM LIMITS: 800000 043237 843248 
STACK LIMITS: O9998909 000777 BH100B 
DISK BLK LIMITS: 909003 000046 000044 
IDENTIFICATION : 62 

PRG XFR ADDRESS: 901000 

TASK ATTRIBUTES: FP,NF 


PROGRAM SECTION ALLOCATION SYNOPSIS: 
<. BLK.>: 881808 632507 931519 

<DTA >: 032518 834151 961442 
<SSDEVT>: 834152 036065 901714 
<SSFSR1>: 836066 642165 9804100 
<SSFSR2>: 942166 042267 688162 
<$SIOB1>: 942270 842473 600204 
<S$S$IOB2>: 942474 842474 BB00B0 
<$SOTST>: 842474 042507 800014 
<SSRESL>: 942519 843235 0886526 

<. ABS.>: OBOHHH BDBBOLG BHHOBO 

*** PILE: RDIN.OBJ:1 TITLE: .MAIN. IDENT: 
<. BLK.>: 9818008 6801147 980158 

MAIN. @@1000-R 


<DTA >: 832518 034151 601442 


*** FILE: PROC1.OBJ;2 TITLE: PROC1 IDENT: 
<. BLK.>: 881158 8681173 060924 
PROC1 981150-R 


<DTA >: 932518 634151 881442 


*** FILE: RPRT.OBJ;2 TITLE: RPRT IDENT: 
<. BLK.>: 081174 681217 0009924 

RPRT @01174-R 
<DTA >: 932518 634151 9861442 


Figure 4-2 
Memory Allocation File for CALC;1 
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In the example CALC;2 in Chapter 3, the user added some code to 


and entered two 


e ACTFIL=1 to eliminate the three active file 


@ PAR=PAR14K to direct the Task Builder to 


options during option input: 


needed by CALC. 


Partition for CALC since the 


use 
user intends to 


buffers 


RDIN, 


not 


a larger 


expand the task. However, this has no effect on 
task building other than to set up a partition 


name for Install to use. 


The memory allocation file shown in Figure 4-3 reflects these changes: 


Because of the 


FILE CALC.TASK;2 MEMORY ALLOCATION MAP 
THIS ALLOCATION WAS DONE ON 13-FEB-75 
AT 14:29 BY TASK BUILDER VERSION RO@9 


*** ROOT SEGMENT: RDIN 


R/W MEM LIMITS: 9089000 940203 949204 
STACK LIMITS: 990008 BH0777 BB1AB00 
IDENTIFICATION : 92 

PRG XFR ADDRESS: 9018008 

TASK ATTRIBUTES: FP,NF 


PROGRAM SECTION ALLOCATION SYNOPSIS: 


<. BLK.>: 981908 932533 931534 
<DTA >: 032534 934175 681442 
<SSDEVT>: 834176 036111 001714 
<SSFSR1>: 836112 837131 981920 
<$SFSR2>: 037132 937233 000182 
<SSIOB1>: 937234 937437 890204 
<S$$IOB2>: 037446 037440 BBRB09 
<SSOTST>: 837448 937453 900014 
<$SRESL>: 937454 940201 809526 
<. ABS.>: 888080 BDVODG DODD 


Figure 4-3 
Memory Allocation File for CALC;2 


additional logic in the program  RDIN, 


the 


task 


allocation increased from 31519 in CALC;1 to 31534 in CALC;2. 


Because the ACTFIL keyword was used, the File 


task c 


SSFSR1 


CALC ;1 CALC ;2 Difference 
ode 31519 31534 + 24 
4100 1920 -3860 
-3034 


4-18 


Storage 


Region 
pool, SSFSR1, decreased from 419@ in CALC;1 to 1928 in CALC;2. 


code 


buffer 
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The use of the ACTFIL keyword saved 3868 bytes. The net saving of 
3024 bytes, when added to the memory requirements for CALC;2, gives 
the memory requirement for CALC;1 


CALC; 2 492604 
DIFF 3034 
CALC ;1 432408 


CHAPTER 5 


OVERLAY CAPABILITY 


This chapter describes the use of the overlay capability to reduce the 


memory requirements of a task. The concept of tree structured 
overlays is introduced and a language for representing this structure 
is defined. Examples are given that illustrate the use of the 


language and the allocation of memory for an overlayed task. 


5.1 OVERLAY DESCRIPTION 


To create an overlay structure, the user divides his task into a 
series of segments; specifically: 


e a single root segment, which is always in memory, and 


e any number of overlay segments, which share memory with one 
another. 


A segment consists of a set of modules and p-sections that can be 
loaded by a single disk access. Segments that overlay each other must 
be logically independent. Two segments are said to be logically 
independent if the components of one segment do not reference and are 
not referenced by any of the components of the other segment. 


When the user defines an overlay structure, he must consider’ the 
general flow of control within his task in addition to the logical 
independence of the overlay segments. Dividing a task into overlays 
saves space, but introduces’ the overhead activity of loading these 
segments into memory as they are needed. The programmer must’ make 
optimization decisions in constructing the overlay just as he does in 
writing the programs. 


There are several large classes of tasks that can be handled 
effectively by an overlay structure. A task that moves sequentially 
through a set of modules is well suited to the use of an overlay 
structure. A task which selects one of a set of modules according to 
the value of an item of input data is also well suited to an _ overlay 
structure. 
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5.1.1 Overlay Structure 


Consider a task, TKl1, which consists of four input files. Each input 
file consists of a single module of the same name as the file. The 
task is built by the command: 


MCR>TKB TK1=CNTRL,A,B,C 


Suppose the user knows that the modules A, B, and C are logically 
independent. In this example: 


A does not call B or C and does not use the data of Bor C, 
B does not call A or C and does not use the data of Aor C, 
C does not call A or B and does not use the data of A or B. 


The user can define an overlay structure in which A, B, and C are 
overlay segments that occupy the same storage. Suppose further that 
the flow of control for the task is as follows: 


CNTRL calls A and A returns to CNTRL, 
CNTRL calls B and B returns to CNTRL, 
CNTRL calls C and C returns to CNTRL, 
CNTRL calls A and A returns to CNTRL. 


The loading of overlays occurs only four times during the execution of 
the task. Therefore, the user can reduce the memory requirements of 
the task without unduly increasing the overhead activity. 


Consider the effect of introducing an overlay structure on_ the 
allocation of memory for the task. Suppose the lengths of the modules 
are as follows: 


CNTRL 19888 bytes 
A 6000 bytes 
B 50099 bytes 
C 1298 bytes 


The memory allocation produced as a result of building the task as a 
single segment on a system with memory mapping hardware is as follows: 


_ 24200 
3 38086 
se 


The memory allocation for a single-segment task requires 24208 bytes. 
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The memory allocation produced as a result of using the overlay 
capability and building a multi-segment task is as follows: 


- 16000 


The multi-segment task requires 16890 bytes. In addition to the 
module storage, additional storage is required for overhead connected 
with handling the overlay structure. This overhead is described later 
and illustrated in the example CALC. 


Observe that the amount of storage required for the task is determined 
by the length of the root segment and the length of the longest 
overlay segment. Overlay segments A and B in this representation are 
much longer than overlay segment C. If the user can divide A and B 
into sets of logically independent modules, further reduction can be 
made in the storage requirements for the task. Segment A is divided 
into a control program, A®, and two overlays, Al and A2. Then, A2 is 
further divided into a main part ,A2, and two overlays ,A21 and A22. 
Similarly, segment B is divided into a control module, B@, and_ two 
overlays, Bl and B2. 


The memory allocation for the task produced by the additional overlays 
defined for A and B is given by the diagram: 


As a single-segment task, TKl required 24206 bytes of storage. The 
first overlay structure reduced the requirement by 6200 bytes. The 
second overlay structure further reduced the storage requirement by 
2200 bytes. 


Observe that a vertical line can be drawn through the memory diagram 
to indicate a state of memory. In the diagram given here, the 
leftmost such line gives memory when CNTRL, A®, and Al are _ loaded: 
the next such line gives memory when CNTRL, AG, A2, and A2l are 
loaded: and so on. 


Observe also that a horizontal line can be drawn through the memory 
diagram to indicate segments that share the same storage. In the 
given diagram, the uppermost such line gives Al, A21, A22, Bl, B2 and 
C, all of which can use the same memory; the next such line gives Al, 
A2, Bl, B2, and C; and so on. 
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5.1.2 Overlay Tree 


The Task Builder provides a language for representing an overlay 
structure consisting of one or more trees. 


A single overlay tree is described first and then the procedure for 
describing multiple overlay trees is given. 


The memory allocation for the previous example can be represented by 
the single overlay tree shown below: 


A21 A22 
Al A2 Bl B2 
AO BO Cc 
es Seer eee ee 
CNTRL 


The tree has a root, CNTRL, and three main branches, A®, BO, and C. 
The tree has six leaves, Al, A2l1, A22, Bl, B2, and C. 


The tree has as many paths as it has leaves. The path down is defined 
from the leaf to the root, for example: 


A21-A2-A@-CNTRL 
The path up is defined from the root to the leaf, for example: 
CNTRL-BO-Bl. 


Understanding the tree and its paths is important to the understanding 
of the overlay loading mechanism and the resolution of global symbols. 


5.1.2.1 Loading Mechanism - Modules can call other modules that exist 
on the same path. The module CNTRL is common to every path of the 
tree and, therefore, can call and be called by every module in _ the 
tree. The module A2 can call the modules A21, A22, A®, and CNTRL; 
but A2 can not call Al, Bl, B2, B® or C. 


When a module calls a module in another overlay segment, the overlay 
segment must be in memory or must be brought into memory. The methods 
for loading overlays are described in the next chapter. 


5.1.2.2 Resolution of Global Symbols in a _ Multi-segment Task - The 


Task Builder performs the same activities in resolving global symbols 
for a multi-segment task as it does for a single segment’ task. The 
rules defined in Chapter 4 for the resolution of global symbols ina 
Single segment task still apply, but the scope of the global symbols 
is altered by the overlay structure. 
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In a single segment task, any global definition can be referenced by 
any module. In a multi-segment task, a module can only reference a 
global symbol that is defined on a path that passes through the 
segment to which the module belongs. 


In a single segment task, if two global symbols with the same name are 
defined, the symbols are multiply defined and (if the values differ) 
an error message is produced. In a multi-segment task two global 
symbols can be defined with the same name as long as the definitions 
are on separate paths. A reference is said to be ambiguous if there 
are multiple definitions on common paths to which the reference could 
be resolved. 


Consider the task TK] and the global symbols Q, R, S, and T. 


A21 A22 
T (def) R(ref) 
Q (xref) 
Al A2 Bl B2 
Q(ref) R(def£) Q (ref) 
R(ref) | 
AO BO Cc 
Q (def) Q (def) 
S (def) S (def) 
T (def) 
CNTRL 
S (ref) 


The following remarks apply to the use of each of the symbols shown in 
the diagram: 


Q The global symbol Q is defined in the segment A® and in the 
segment B@. The reference to Q in segment A22 and the 
reference to Q in segment Al are resolved to the definition 
in A@®. The reference to Q in Bl is resolved to refer to the 
definition of B®. The two definitions of Q are distinct in 
all respects and occupy different memory allocations. 


R  -The global symbol R is defined in the segment A2. The 
reference to R in A22 is resolved to the definition in A2 
because there is a path to the reference from the definition 
(CNTRL-A@-A2-A22) . The reference to Rin Al, however, is 
undefined because there is no definition for R on a= path 
through Al. 


S The global symbol S is defined in A® and B®. References to S 
from Al, A21 or A22 are resolved to the definition in A@ and 
references to S in Bl and B2 are resolved to the definition 
in BQO. However, the reference to S in CNTRL cannot be 
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resolved because there are two definitions of S on _ separate 
paths through CNTRL. S is ambiguously defined. 


T The global symbol T is defined in A21 and A®. Since there is 
a single path through the two definitions (CNTRL-A®-A2-A21), 
the global symbol T is multiply defined. 


5.1.2.3 Resolution of P-sections in a Multi-segment Task - Each 


p-section has an attribute that indicates whether the p-section is 
local (LCL) to the segment in which it is defined or of global  (GBL) 
extent. 


Local p-sections with the same name can appear in any number of 
segments. Storage is allocated for each local p-section in the 
segment in which it is declared. Global p-sections of the same name, 
however, must be resolved by the Task Builder. 


When a global p-section is defined in several overlay segments along a 
common path, the Task Builder allocates all storage for the p-section 
in the overlay segment closest to the root. 


FORTRAN common blocks are translated into global p-sections with the 
overlay attribute. Suppose that in the task TK1. the common block 
COMA is defined in modules A2 and A21. The Task Builder allocates the 
storage for COMA in A2 because that segment is closer to the root than 
the segment which contains A2l1. 


However, if the programs A@ and B® use a common block COMAB, the _ Task 
Builder allocates the storage for COMAB in both the segment which 
contains A® and the segment which contains B@. A® and B@ can not 
communicate through COMAB. When the overlay segment containing B# is 


loaded, any data stored in COMAB by A@ is lost. 


The tree for the task TK] including the allocation of the common 
blocks COMA and COMAB is: 


A21 A22 
Al A2 Bl B2 
| COMA | | 
AO BO Cc 
COMAB COMAB | 
CNTRL 


The allocation of p-sections can be specified by the user. If A@ and 
B@ need to share the contents of COMAB, the user can force the 
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allocation of this p-section into the root segment by the use of the 
-PSECT directive, described in Section 5.1.3.4. 


5.1.3 Overlay Description Language (ODL) 


The Task Builder provides a language that allows the user to describe 
the overlay structure. The overlay description language (ODL) 
contains five directives by which the user can describe the overlay 
structure of his task. 


An overlay description consists of a series of ODL directives. There 
Must be one .ROOT directive and one .END directive. The .ROOT 
directive tells the Task Builder where to start building the tree and 
the .END directive tells the Task Builder where the input ends. 


5.1.3.1 .ROOT and .END Directives - The arguments of the ROOT 
directive make use of two operators to express concatenation and 
overlaying. A pair of parentheses delimits a group of segments’ that 
start at the same location in memory. The maximum number of nested 
parentheses cannot exceed 32. 


@e The operator dash “-’ indicates the concatenation of storage. 
For example, ‘“X-Y° means that the memory allocation must 
contain X and Y simultaneously. So X and Y are allocated in 
sequence. 


e The operator comma °,° appearing within parentheses indicates 
the overlaying of storage. For example, “Y,Z° means that 
memory can contain either Y or Z. Therefore Y and @Z are 
share storage. 


This operator is also used to define multiple tree 
structures, as described in 5.1.4. 


Consider the overlay description language directives: 


~ROOT X-(Y,2Z-(21,22) ) 
- END 


These directives describe the following tree and its corresponding 
memory diagram: 


Y Z 
Xx 
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To create the overlay description for the task TK1 described earlier 
in this chapter, the user creates a file TFIL that contains the 
directives: 


-ROOT CNTRL- (AG- (Al ,A2- (A21,A22)) ,B®-(B1,B2) ,C) 
- END 


To build the task with that overlay structure, the user types: 
MCR>TKB TK1=TFIL/MP 


The switch MP tells the Task Builder that there is only one input 
file, TFIL.ODL, and that file contains an overlay description for the 
task. 


5.1.3.2 .FCTR Directive - The tree that represents’ the overlay 
structure can be complicated. The overlay description language 
includes another directive, .FCTR, which allows the user to build 
large trees and represent them systematically. 


The .FCTR directive allows the user to extend the tree description 
beyond a single line. Since there can be only one .ROOT directive, 
the .FCTR directive must be used if the tree definition exceeds one 
line. The .FCTR directive, however, can also be used to introduce 
clarity in the representation of the tree. 


The maximum number of nested .FCTR levels is 32. 


To simplify the tree given in the file TFIL the .FCTR directive is 
introduced into the overlay description language as follows: 


-ROOT CNTRL- (AFCTR,BFCTR,C) 


AFCTR: -FCTR A@- (Al ,A2-(A21,A22) ) 
BFCTR: -FCTR BO-(B1,B2) 
- END 


The label “BFCTR’, is used in the .ROOT directive to designate the 
argument of the .FCTR directive, “BO-(B1,B2)°. The resulting overlay 
description is easier to interpret than the original description. The 
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tree consists of a root, CNTRL, and three main branches. ‘Two of the 
Main branches have sub-branches. 


The .FCTR directive can be nested. The user can modify TFIL as 
follow: 


~-ROOT CNTRL- (AFCTR,BFCTR,C) 


AFCTR: -FCTR A@-(A1l,A2FCTR) 
A2FCTR: -FCTR A2-(A21,A22) 
BFCTR: -FCTR B@-(B1,B2) 

- END 


The decision to use the .FCTR directive is based on considerations of 
space, style and readability of a complex ODL file. 


5.1.3.3 ..NAME Directive - The .NAME directive allows a segment name 
to be defined and included at any appropriate point in the tree. The 
defined name must be unique with respect to filenames, p-section 
names, .FCTR labels and other segment names that are used in the 
overlay description. 


The .NAME directive is used to uniquely identify a segment that is to 
be loaded into memory by means of the Manual Load Method described in 
Chapter 6. 


Suppose that, in the definition of the tree for TKl, the user wants to 
give a name to every main branch of the tree. He defines three names 
and includes these new names in the overlay description for the tree. 
TFIL is modified as follows: 


»~NAME BRNCH1 
-NAME BRNCH2 
-NAME BRNCH3 
-ROOT CNTRL~ (BRNCH1-AFCTR, BRNCH 2-BFCTR, BRNCH3-C) 


AFCTR: -FCTR A@- (Al,A2-(A21,A22) ) 
BFCTR: -FCTR BO-(B1,B2) 
- END 


Note that, in scanning down all .FCTR directives for a particular 
segment, the most recent (i.e., at deepest level) .NAME directive 
applied will be adopted if there is more than one .NAME directive for 
the segment. 


5.1.3.4 _.PSECT Directive - The .PSECT directive allows the placement 
of a global p-section to be specified directly. The name of the 
p-~section and its attributes are given in the .PSECT directive. Then, 
the name can be used explicitly in the definition of the tree to 
indicate the segment in which the p-section is to be allocated. 


Suppose the user encountered a problem in communication resulting from 
the \joverlay description for MTKl. The user was careful about the 
logical independence of the modules in the overlay segment, but’ the 


user failed to take into account the logical independence requirement 
of multiple executions of the same overlay segment. 
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The flow of the task TKl1, as described earlier in this chapter, is 
summarized in the following way. CNTRL calls each of the overlay 
segments and the overlay segment returns to CNTRL in the _ following 
order: A,B,C,A. The module A is executed twice. The overlay segment 
containing A must be reloaded for the second execution of A. 


The module A uses the common block DATA3 and the Task Builder 
allocates DATA3 in the overlay segment containing A. The first 
execution of A stores some results in DATA3. The second execution of 
A requires these values. In the present overlay description, however, 
the values calculated by the first execution of A are overlaid. When 
the segment containing A is read in for the second execution, the 
common block is in its initial state. 


The use of a .PSECT directive forces the allocation of DATA3 into the 
root segment to permit the two executions of A to communicate. MTFIL 
is modified as follows: 


-PSECT DATA3,RW,GBL,REL,OVR 
-ROOT CNTRL-DATA3-— (AFCTR,BFCTR,C) 


AFCTR: -FCTR A@-(Al1,A2-(A21,A22) ) 
BFCTR: -FCTR B@-(B1,B2) 
- END 


The attributes RW,GBL,REL and OVR are described in Chapter 4. 


5.1.4 Multiple Tree Structures 


The Task Builder allows the specification of more than one tree within 
the overlay structure. A structure containing multiple trees has the 
following properties: 


1. Storage is not shared among trees. The total storage 
required is the sum of the longest path on each tree. 


2. Each path in a tree is common to all paths on every other 
tree. 


These properties allow modules, that would otherwise have to reside in 
the root segment, to be contained in an overlay tree. 


Such overlay trees within the structure consist of a main tree and one 
or more co-trees. The root segment of the main tree is loaded by the 
monitor when the task is made active while segments within each 
co-tree are loaded through calls to the overlay runtime system. 


Except for the above distinction, all overlay trees have identical 
characteristics. That is, each tree must have a root segment and 
possibly one or more overlay segments. 


The following paragraphs describe the procedure for specifying 
multiple trees in the overlay description language and illustrate the 
use of co-trees to reduce the memory required by a task. 
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5.1.4.1 Defining a Multiple Tree Structure - Multiple tree structures 
are specified within the overlay description language by extending the 
function of the comma “,” operator. As previously discussed, this 
operator, when included within parentheses, defines a pair of segments 
that share storage. The inclusion of the comma operator outside all 
parentheses delimits overlay trees. The first overlay tree thus 
defined is the main tree. Subsequent trees are co-trees. 


Consider the following : 


- ROOT X,Y 
X: -FCTR X@- (X1,X2,X3) 
ba -FCTR Y@-(Y1,Y2) 

- END 


Two overlay trees are specified. A main tree containing the root 
segment X@ and three overlay segments and a co-tree consisting of root 
segment Y@ and two overlay segments. The Executive loads segment x9 
into memory when the task iS activated. The task then loads the 
remaining segments through calls to the overlay runtime system. 


A co-tree must have a root segment to establish linkages to the 
overlay segments within the co-tree. Logically, these root segments 
need not contain code or data. (Such modules can be resident in the 
main root). A segment of this type termed a “null segment’, may be 
created by means of the .NAME directive. The previous example is 
modified as shown below to include a null segment. 


- ROOT X,Y 

Xs -FCTR XO9-YO-(X1,X2,X3) 
- NAME YNUL 

¥: -FCTR YNUL- (Y1,Y2) 
- END 


The null segment “YNUL” is created, using the .NAME directive, and 
replaces the co-tree root that formerly contained Y®@.OBJ. Y@ now 
resides in the main root. 


5.1.4.2 Multiple Tree Example - The following example illustrates the 
use of multiple trees to reduce the size of the task. 


Suppose that in the task TKl1, the root segment CNTRL consists of a 
small dispatching routine and two long modules, CNTRLX and CNTRLY. 
CNTRLX and CNTRLY are logically independent of each other, are 
approximately equal in length, and must access modules on all the 
paths of the main tree. 


The user can define a co-tree for CNTRLX and CNTRLY and effect a 
saving in the storage reguired by the task. He modifies the overlay 
description in TFIL as follows: 


-NAME CNTRL2 
-ROOT CNTRL- (AFCTR,BFCTR,C) ,CNTRL2-(CNTRLX,CNTRLY) 


- END 
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The co-tree is defined at the ‘zeroth’ parenthesis level in the .ROOT 
directive. A co-tree must have a root segment, to establish linkages 
to the overlay segments within the co-tree. When no code or data 
logically belong in the root, the .NAME directive can be used to 
create a null root segment. 


The tree for the task TK1 now is: 


A21 A22 
Al A2 Bl B2 CNTRLX CNTRLY 
AQ BO Cc 
CNTRL CNTRL2 


The corresponding memory diagram is: 


The specification of the co-tree decreases the storage allocation by 
4900 bytes. CNTRLX and CNTRLY can still access modules on all the 
paths of the main tree. The only requirement imposed by the 
introduction of the co-tree is the logical independence of CNTRLX and 
CNTRLY. 


Any number of co-trees can be defined. Additional co-trees can access 
all the modules in the main tree and in the other co-trees. 


163) 
i 


12 
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5.1.5 Overlay Core Image 


The core image for a task with an overlay structure can be represented 
by the following diagram: 


co-tree 
overlay 
segment 


co-tree 
root segment 


co-tree 


overlay 
segments 


co-tree 
root segment 


Main tree 
root 
segment 


The stack is described in Chapter 4. 
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The root segment of the main tree contains all the modules that are 
resident in memory throughout the entire execution of the task, along 
with the segment tables, and if the autoload loading method is’ used, 
the autoload vectors. 


autoload 
vectors 


main tree 
root segment 


segment 


tables 


code and 
data 


The segment table contains a segment descriptor for every segment in 
the task. The descriptor contains information about the load address, 
the length of the segment, and the tree linkages. The segment table 
is described in detail in Appendix C. 


Autoload vectors appear in every segment that calls modules in another 
segment that is further from the root of the tree. Autoload vectors 
are described in connection with loading mechanisms in Chapter 6 and 
the detailed composition of the autoload vector is given in Appendix 
Cy 

The main tree overlay region consists of memory allocated for the 


overlay segments of the main tree. The overlays are read into this 
area of memory as they are needed. 


autoload vectors 
code and data 


autoload vectors 
code and data 


The co-tree overlay region consists of memory allocated for the 
overlay segments of the co-trees. 


overlay 


overlay 


overlay 
segment 
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The co-tree root segment contains the modules that, once loaded, must 
remain resident in memory. 


5.2 EXAMPLE: CALC;3 


The version of CALC introduced earlier is now ready for the addition 
of two more data processing routines, PROC2 and PROC3. These new 
algorithms are logically independent of each other and of PROCI1. The 
third algorithm, PROC3, contains two independent routines SUB1 and 
SUB2. 


The user defines an overlay structure for CALC as follows: 


SUB1 SUB2 
PROC1 PROC2 PROC3 


RDIN 
RPRT 


5.2.1 Defining the ODL File 


The user constructs a file, CALTR, of ODL directives to represent the 
tree for CALC, as follows: 


MCR>EDI 


pam nianatasine ny 


EDI>CALTR.ODL 
[EDI --— CREATING NEW FILE] 
INPUT 
~ROOT RDIN-RPRT-* (PROC1,PROC2,P3FCTR) 
P3FCTR: .FCTR PROC3- (SUB1,SUB2) 
- END 
*EX 


NOTE 


The “*° in the ODL description is the 
autoload indicator and is described in 
Chapter 6. 
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5.2.2 Building the Task 


The user builds the task with the same options as in the example of 
Chapter 3. The names of the input files are replaced by a single 
filename that designates the file containing the overlay description: 


MCR>TKB 
TKB>CALC ;3, LP: /SH=CALTR/MP 
ENTER OPTIONS: 
TKB>PAR=PAR14K 
TKB>ACTFIL=1 

TKB>// 


5.2.3 Memory Allocation File for CALC;3 

The short memory allocation file for this multi-segment task consists 
of one page per segment. For convenience the pages are compressed in 
this manual. See Figure 5-l. 


The memory diagram for CALC;3 is: 


_— 37724 
aa 37659 
— 
— 3794 
— 36392 
_ 36199 
PROCL PROC2 
PROC3 
[Seguent Tables and Autoload vectors | yyy 
Segment Tables and Autoload Vectors = 34232 
FORTRAN Buffers 

cae 23312 
_ 2165¢ 

RDIN 
— 1p 

Stack 

piste a, @ 


If the user had not used an overlay structure for the task, the memory 
reguirement of the task would have been: 


ROOT 34414 
PROC] 1464 
PROC 2 1664 
PROC3 2370 
SUB1 644 
SUB2 720 

44140 
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FILE CALC.TSK;3 MEMORY ALLOCATION MAP 
THIS ALLOCATION WAS DONE ON 31-MAR-75 
AT 15:47 BY TASK BUILDER VERSION RQ9 


***k ROOT SEGMENT: RDIN 


R/W MEM LIMITS: @@0000 834413 634414 
STACK LIMITS: 9000008 800777 901900 
DISK BLK LIMITS: 9009003 8090408 900036 
IDENTIFICATION : SFORT 
PRG XFR ADDRESS: 601909 
TASK ATTRIBUTES: FP,NF 


PROGRAM SECTION ALLOCATION SYNOPSIS: 


<. BLK.>: 9810800 621647 9828659 
<DTA >: 021658 823311 901442 
<S$FIOF >: 623312 625271 861768 
<$FIOI >: 925272 625675 688404 
<SFIOL >: 925676 9825676 880900 
<$FIO1 >: 925676 927425 991538 
<$FIO2 >: 627426 6827463 9880036 
<SSALER>: 627464 6275807 860024 
<$SAOTS>: 9627518 638433 900724 
<$SAUTO>: 938434 938567 608134 
<SSDEVT>: 930578 931777 681218 
<SSFSR1>: 832009 633017 6819820 
<SSFSR2>: 9336028 633121 680182 
<$$IOB1>: 833122 633325 8080204 
<$SIOB2>: 833326 633326 880008 
<SSOBF1>: 833326 833435 680119 
<S$SOBF2>: 833436 933436 900800 
<$SOVCT>: 933436 633711 690254 
<SSOVDT>: 808090 8860000 800900 
<S$SRESL>: 633712 934231 6096328 
<. ABS.>: @608000 O80090 880000 


*** SEGMENT: PROC] 


R/W MEM LIMITS: 934414 636077 901464 
DISK BLK LIMITS: 909041 980042 880002 


Figure 5-1 
Memory Allocation File for CALC;3 
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PROGRAM SECTION ALLOCATION SYNOPSIS: 


<. BLK.>: 034414 834435 988622 
<ADTA >: 834436 836077 991442 


*** SEGMENT: PROC2 

R/W MEM LIMITS: 634414 636277 6991664 
DISK BLK LIMITS: 6908043 980044 890002 
PROGRAM SECTION ALLOCATION SYNOPSIS: 
<. BLK.>: 934414 034635 998222 

<ADTA >: 834636 936277 991442 

*** SEGMENT: PROC3 

R/W MEM LIMITS: 634414 637983 092378 
DISK BLK LIMITS: 9099945 9099047 880003 
PROGRAM SECTION ALLOCATION SYNOPSIS: 
<. BLK.>: 934414 935341 900726 

<ADTA >: 8935342 837903 9801442 


*** SEGMENT: SUBI1 


R/W MEM LIMITS: 937904 037647 860644 
DISK BLK LIMITS: 999050 890850 BBB001 


PROGRAM SECTION ALLOCATION SYNOPSIS: 


<. BLK.>: 937004 037647 990614 


*** SEGMENT: SUB2 


R/W MEM LIMITS: 937004 937723 8007290 
DISK BLK LIMITS: 999051 800051 OBB001 


PROGRAM SECTION ALLOCATION SYNOPSIS: 


<. BLK.>: 037004 037721 980716 


Figure 5-1 (cont.) 
Memory Allocation File for CALC;3 
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5.3 EXAMPLE CALC;4 


After examining the memory allocation file for CALC;3, the user 
observes that the Task Builder has allocated ADTA in the overlay 
segments PROC1, PROC2, and PROC3, since all of these segments are 
equidistant from the root. 


The user knows, however, that these segments need to communicate with 
each other through ADTA. In the existing allocation, any values 
placed in ADTA by PROC] are lost when PROC2 is loaded. Similarly, any 
values stored in ADTA by PROC2 are lost when PROC3 is loaded. 


The user adds a .PSECT directive to the overlay description to force 
ADTA into the root segment so that PROC], PROC2, and PROC3 can 
communicate with each other. CALTR is modified as follows: 


-ROOT RDIN~RPRT-ADTA-* (PROC1,PROC2, P3FCTR) 
P3FCTR: -FCTR PROC3- (SUB1,SUB2) 

-PSECT ADTA,RW,GBL,REL,OVR 

- END 


The task is built as in CALC;3 and the resulting memory allocation 
file is represented by the following diagram: 


Segment Table and Autoload Vectors 35674 


FORTRAN Buffers 
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FILE CALC.TSK;4 MEMORY ALLOCATION MAP 
THIS ALLOCATION WAS DONE ON 31-MAR-75 
AT 15:44 BY TASK BUILDER VERSION R099 


***ROOT SEGMENT: RDIN 


R/W MEM LIMITS: 900999 936957 9360690 
STACK LIMITS: 9098008 009777 9081000 
DISK BLK LIMITS: 9889003 800041 0990037 
IDENTIFICATION : $FORT 
PRG XFR ADDRESS: 901098 
TASK ATTRIBUTES: FP,NF 


PROGRAM SECTION ALLOCATION SYNOPSIS 


<. BLK.>: 8081000 921647 920659 
<ADTA >: 821659 923311 901442 
<DTA >: 023312 924753 981442 
<$FIOF >: 924754 926733 961768 
<$FIOI >: 026734 927337 9080404 
<S$FIOL >: 8027340 927348 080000 
<SFIO1] >: 027348 931967 981538 
<$F1862 >: 631878 631125 980036 
<SSALER>: 931126 931151 980924 
<$SAOTS>: 831152 932075 998724 
<$$SAUTO>: 9328976 832231 886134 
<SSDEVT>: 932232 933441 981219 
<SSFSR1>: 933442 034461 981920 « 
<SSFSR2>: 034462 934563 099102 
<SSIOB1>: 934564 934767 990204 
<$SIOB2>: 834776 034778 O0BB000 
<SSOBF1>: 034778 935077 988119 
<SSOBF2>: 835109 935180 880000 
<$SOVCT>: 935198 835353 889254 
<SSOVDT>: 880000 BHBBO0 BHB000 
<SSRESL>: 835354 935673 088320 
<. ABS.>: O98000 BHDBBD BHDDBD 


FIGURE 5-2 
Memory Allocation File for CALC; 4 
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*** SEGMENT: PROC1 


R/W MEM LIMITS: 936068 936193 808024 
DISK BLK LIMITS: 980942 900042 900001 


PROGRAM SECTION ALLOCATION SYNOPSIS: 


<. BLK.>: 836060 936181 899022 


*** SEGMENT: PROC2 


R/W MEM LIMITS: 636968 8363803 096224 
DISK BLK LIMITS: 6890043 880043 O08001 


PROGRAM SECTION ALLOCATION SYNOPSIS: 


<. BLK.>: 936068 836301 898222 


***® SEGMENT: PROC3 


R/W MEM LIMITS: 8368068 937607 900730 
DISK BLK LIMITS: 990044 8009044 Q00001 


PROGRAM SECTION ALLOCATION SYNOPSIS: 


<. BLK.>: 936968 9378005 889726 


*** SEGMENT: SUB1 


R/W MEM LIMITS: 9378018 637653 860644 
DISK BLK LIMITS: 98908045 989045 800001 


PROGRAM SECTION ALLOCATION SYNOPSIS: 


<. BLK.>: 9378018 837653 998644 


*** SEGMENT: SUB2 


R/W MEM LIMITS: 937818 037727 9860726 
DISK BLK LIMITS: 906046 909946 0980001 


PROGRAM SELECTION ALLOCATION SYNOPSIS: 
<. BLK.>: 937018 837725 990716 


Figure 5-2 (cont.) 
Memory Allocation File for CALC;4 


5.4 
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SUMMARY OF THE OVERLAY DESCRIPTION LANGUAGE 


1s 


An overlay structure consists of one or more trees. Each 
tree contains at least one segment. A segment is a set of 
modules and p-sections that can be loaded by a single disk 
access. 


A tree can have only one root segment, but it can have any 
number of overlay segments. 


The overlay description language provides five directives for 
specifying the tree representation of the overlay structure, 
namely: 


-ROOT 
- END 
-PSECT 
-FCTR 
- NAME 


These directives can appear in any order in the overlay 
description, subject to the following restrictions: 


a. There can be only one .ROOT and one .END directive. 


b. The .END directive must be the last directive, since it 
terminates input. 


The tree structure is defined by the operators ‘“-"° (hyphen) 
and °,° comma (hyphen) and by the use of parentheses. 


The operator “-° indicates that its arguments are to be 
concatenated and thus co-exist in memory. The operator °,° 
(comma) within parentheses indicates that its arguments are 
to be overlaid and thus share memory. The operator °,”° not 
enclosed in parentheses delimits overlay trees. The 
parentheses group segments’ that begin at the same point in 
memory. 


For example, 
~-ROOT A-B-(C,D-(E,F) ) 


defines an overlay structure with a root segment consisting 
of the modules A and B. In this structure, there are four 
overlay segments, C, D, E, and F. The outer parenthesis pair 
indicates that the overlay segments C and D start at the same 
location in memory. 


The simplest overlay description consists of two directives, 
as follows: 


-ROOT A-B-(C,D-(E,F) ) 
- END 


Any number of the optional directives (.FCTR, .PSECT, and 
»-NAME) can be included. 
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The .ROOT directive defines the overlay structure. The 
arguments of the .ROOT directive are one or more of the 
following: 

e File specifications as described in 2.3.1 

e Factor labels 

e Segment names 

e P-section names 

The .END directive is required to terminate input. 

The .FCTR directive provides a means for replacing text by a 

symbolic reference (the factor label). This replacement is 

useful for two reasons: 

a. The .FCTR directive effectively extends the text of the 
-ROOT directive to more than one line and thus allows 
complex trees to be represented. 

b. The .FCTR directive allows the overlay description to be 
written in a form that makes the structure of the tree 
more apparent. 


For example: 


-ROOT A-(B-(C,D) ,E-(F,G) ,H) 
- END 


can be expressed, using the .FCTR directive, as follows: 


Fl: -FCTR B-(C,D) 
F22 -FCTR E-(F,G) 
- END 


The second representation makes it clear that the tree has 
three main branches. 


8 The .PSECT directive provides a means for directly 
specifying the segment in which a p-section is placed. 


The .PSECT directive gives the name of the p-section and its 
attributes. For example: 


-PSECT ALPHA,CON,GBL,RW,1,REL 


ALPHA is the p-section name and the remaining arguments are 
attributes. P-section attributes are described in Chapter 4. 
The p-section name must appear first on the .PSECT directive, 
but the attributes can appear in any order or can be omitted. 
If an attribute is omitted, a default assumption is made. 
For p-section attributes the default assumptions are: 


RW,1I,LCL,REL,CON 


10. 
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In the above example, therefore, it is only necessary to 
specify the attributes that do not correspond to the default 
assumption: 


-PSECT ALPHA,GBL 


The .NAME directive provides a means for defining a segment 
name for use in the overlay description. This directive is 
useful for creating a null segment or naming a segment’ that 
is to be loaded manually. If the .NAME directive is not 
used, the name of the first file, or p-section in the segment 
is used to identify the segment. 


The .NAME directive defines a name, as follows: 
-NAME NEWNM 


The defined name must be unique with respect to the names of 
p-sections, segments, files, and factor labels. If more than 
one .NAME directive is applied to a segment (via multiple 
-FCTR directives), the name encountered last in the scan down 
the ODL will be applied. 


A co-tree can be defined by specifying an additional tree 
structure in the .ROOT directive. The first overlay tree 
description in the .ROOT directive is the main tree. 
Subsequent overlay descriptions are co-trees. For example: 


-ROOT A-B-(C,D-(E,F)) ,X-(Y¥,Z) ,Q-(R,S,T) 


The main tree in this example has the root segment consisting 
of files A.OBJ and B.OBJ; two co~-trees are defined; the 
first co-tree has the root segment X and the second co-tree 
has the root segment Q. 


CHAPTER 6 


LOADING MECHANISMS 


When the user divides a task into overlay segments, he becomes 
responsible for loading these overlay segments into memory as they are 
needed. The degree of involvement on the part of the user can _ range 
from minimum, in which he specifies that the loading of all segments 
be handled automatically, to maximum, in which he explicitly controls 
the asynchronous loading of each segment and handles any errors that 
occur aS a result of the load request. 


This chapter describes the loading mechanisms available to the user. 
There are two methods for loading overlays: 


Autoload in which the Overlay Runtime System is 
automatically invoked to load those segments that 
are marked by the user. 


Manual Load in which the user includes explicit calls to the 
Overlay Runtime System in his programs. 


In the autoload method, loading and error recovery are handled by the 
Overlay Runtime System. In the manual load method, the user handles 
loading and error recovery explicitly. The user has more control and 
can specify whether loading is to be done synchronously or 
asynchronously. 


The user must decide which method to use, because both methods can not 
be used in a_e single task. Both methods offer advantages. The 
autoload method allows the user to divide a task into segments without 
explicit calls to load overlays. The manual load method saves space 
and gives the user full control over the loading process. 


The user is responsible for loading the overlay segments of the main 
tree, and if co-trees are used, the root segment as well as the 
overlay segments of the co-tree. Once loaded, the root segment of the 
co-tree remains in memory. 
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6.1 AUTOLOAD 


If the user decides to use the autoload method, he places the autoload 
indicator “°*” in the ODL description of the task at the points where 
loading must take place. The execution of a transfer of control 
instruction to an autoloadable segment up-tree automatically initiates 
the autoload process. 


6.1.1 Autoload Indicator 


The autoload indicator, °*°, marks the construct to which it is 
applied as autoloadable. If the autoload indicator is applied to a 
parenthesized construct then every name within the parentheses is 
marked autoloadable. Applying the autoload indicator at the outermost 
parentheses level of the ODL tree description marks every module in 
the overlay segments autoloadable. 


Consider the example TK1 of Chapter 5, and suppose further that 
segment C consists of a set of modules Cl, C2, C3, C4 and C5. The 
tree diagram for TKl then is: 


A21 A22 
| C5 
Al A2 Bl B2 C4 
C3 
C2 
AO BO cl 
CNTRL 


If the user introduces the autoload indicator at the outermost 
parentheses level, he is assured that, regardless of the flow of 
control within the task, a module is always properly loaded when it is 
called. The ODL description for the task with this provision then is: 


~ROOT CNTRL-* (AFCTR, BCTR,CFCTR) 


AFCTR: -FCTR A@—-(Al1,A2- (A21,A22) ) 
BFCTR: -FCTR B@-(B1,B2) 
CFCTR: -FCTR C1-C2-C3~C4-C5 

- END 


To be assured that all modules of a co-tree are properly loaded, the 
user muSt mark the root segment as well as the outermost parentheses 
level of the co-tree, as follows: 


-ROOT CNTRL-* (AFCTR,BFTCR,CFCTR) ,*CNTRL2-—* (CNTRLX,CNTRLY) 


The above example assumes that one or more modules’ containing 
executable code reside in CNTRL2. 
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The autoload indicator can be applied to the following constructs: 


e Filenames - to make all the components of the file 
autoloadable. 

e Parenthesized ODL tree descriptions - to make all the names 
within the parentheses autoloadable. 

e P-section names - to make the p-section autoloadable. The 
p-section must have the I (instruction) attribute. 

e Defined names introduced by the .NAME directive - to make 


all components of the segment to which the name applies 


autoloadable. 


® Factor label names - to make the first irreducible component 


of the factor autoloadable. If the entire factor 


enclosed in parentheses, then the entire factor is 
autoloadable. 


is 


Made 


Suppose the user introduces two .PSECT directives and a_e .NAME 
directive into the ODL description for TKl and then applies autoload 


indicators in the following way: 


-ROOT CNTRL- (*AFCTR,*BFCTR, *CFCTR) 


AFCTR: -FCTR A@-*ASUB1—-ASUB2-* (Al,A2- (A21,A22) ) 
BFCTR: -FCTR (BO-(B1,B2) ) 
CFCTR: -FCTR CNAM-C1-C2-C3-C4-C5 

~NAME CNAM 


-PSECT ASUB1,I,GBL,OVR 
-PSECT ASUB2,1I,GBL,OVR 
- END 


The interpretation for each autoload indicator in the overlay 


description is as follows: 


*AFCTR The autoload indicator is applied to a factor label 
name, so the first irreducible component of that 
factor, A@, is made autoloadable. 

*BFCTR The autoload indicator is applied to a factor label 
name, so the first irreducible component of that 
factor, (BO-(B1l,B2)), is made autoloadable. 

*CFCTR Again, the autoload indicator is applied to a factor 


label name, so the first irreducible component, CNAM, 


of the factor is made autoloadable. CNAM, however, 


is 


a defined name introduced by a .NAME directive, so all 
the components of the segment to which the name applies 


are made autoloadable; that is, Cl, C2, C3, C4, and 
Co. 
*ASUB1 The autoload indicator is applied to a p-section name, 
so the p-section ASUB1 is made autoloadable. 
*(A1,A2-(A21,A22)) The autoload indicator is applied to a 


parenthesized ODL description so every name within the 


parentheses is made autoloadable; that is, Al, 
A21, and A22. 


A2, 
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The net effect uf the above ODL description is to make every name 
except ASUB2 autoloadable. 


6.1.2 Path~-loading 


Autoload uses the technique of path-loading. That is, a call from a 
segment to a segment up-tree (farther away from the root) requires 
that all the segments on the path from the calling segment to _ the 
called segment to be resident in memory. Path loading is confined to 
the tree in which the called segment resides. A call from a segment 
in another tree results in the loading of all segments on the path in 
the second tree from the root to the called module. 


Consider again the example TKl and the tree diagram: 


A2l1 A22 
| C5 
Al A2 
AO 


Bl B2 c4 
C3 
C2 
Fe cl 
CNTRL 


Tf CNTRL calls A2, then all the modules between the calling module 
CNTRL and the called module A2 are loaded. In this case modules Ag 
and A2 are loaded. 


The Overlay Runtime System keeps track of the segments in memory and 
only issues load requests for those segments not in memory. If, in 
the above example, CNTRL called Al and then called A2, A® and Al _ are 
loaded first and then A2 is loaded. A@ is not loaded when A2 is 
loaded because it is already in memory. 


A reference from a segment to a segment down-tree (closer to the root) 
is resolved directly. For example, if A2 calls A®, then the reference 
is resolved directly because AZ is known to be in memory as ae result 
of the path-loading that took place in the call to A2. 


6.1.3 Autoload Vectors 


When the Task Builder sees a reference from a segment to an 
autoloadable segment up-tree, it generates an autoload vector for the 
referenced global symbol. The definition of the symbol is changed to 
an autoload vector table entry. The autoload vector has the following 
format: 
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SAUTO 


SEGMENT DESCRIPTOR ADDR. 
ENTRY POINT ADDRESS 


Observe that a Transfer of Control instruction to the referenced 
global symbol executes the call to the autoload routine, SAUTO 
contained in the autoload vector. 


An exception iS made in the case of a p-section with the D (data) 
attribute, References from a segment to a global symbol up-tree in a 
p-section with the D attribute are resolved directly. 


Since the Task Builder can obtain no information about the flow of 
control within the task, it often generates more autoload vectors than 
are necessary. The user, however, can apply his knowledge of the flow 
of control of his task and his knowledge of path-loading to determine 
the placement of autoload indicators. By placing the autoload 
indicators only at the points where loading is actually required, the 
user can minimize the number of autoload vectors generated for the 
task. 


Suppose that in TKl all the calls to overlays originate in the root 
segment. That is, no module in an overlay segment calls outside its 
overlay segment. Suppose further that the root segment CNTRL has’~ the 
following contents: 


PROGRAM CNTRL 
CALL Al 
CALL A21 
CALL A2 
CALL AQ 
CALL A22 
CALL B@ 
CALL Bl 
CALL B2 
CALL Cl 
CALL C2 
CALL C3 
CALL C4 
CALL C5 
END 
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If the autoload indicator is placed at the outermost parentheses 
level, thirteen autoload vectors are generated for this task. 


The user observes that since A2 and A® are loaded by path loading to 
A21, the autoload vectors for A2 and A® are unnecessary. He observes, 
further, that the call to Cl loads the segment which contains C2, C3, 
C4 and C5; therefore autoload vectors for C2 through C5 are 
unnecesSary. 


The user eliminates the unnecessary autoload vectors by placing the 
autoload indicator only at the points where loading is required, as 
follows: 


-ROOT CNTRL- (AFCTR, *BFCTR,CFCTR) 


AFCTR: -FCTR A@-(*A1,A2-* (A21,A22) ) 
BFCTR: -FCTR (BO-(B1,B2) ) 
CFCTR: ~FCTR *C1-C2-C3-C4-C5 

- END 


With this ODL description, the Task Builder generates only seven 
autoload vectors, namely those for Al, A21, A22, B&O, Bl, B2, and Cl. 


6.2 MANUAL LOAD 


If the user decides to use the manual load method of loading segments, 
explicit calls to the $LOAD routine must be included in the programs. 
These load requests give the name of the segment to be loaded _ and 
optionally give information necessary to perform asynchronous load 
requests and to handle unsuccessful load requests. 


The SLOAD routine does not path-load. A call to $LOAD always’ results 
in the segment named in the load request being loaded and only that 
segment being loaded. 


The MACRO-11 programmer calls the S$LOAD routine directly. The FORTRAN 
programmer is provided with the subroutine “MNLOAD’. 


6.2.1 Manual Load Calling Sequence 
The MACRO-11 programmer calls $LOAD, as follows: 


MOV #PBLK,R@ 
CALL SLOAD 


where PBLK labels a parameter block with the following format: 


PBLK: - BYTE length,event-flag 
-RAD5@ /seg-name/ 
.- WORD I/O-status 
- WORD AST-trp 
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The user must specify the following parameters: 


length the length of the parameter block (3 - 5 words) 
event-flag the event flag number, used for asynchronous 
loading. If the event-flag number is zero, 


synchronous loading is performed. 


seg-name the name of the segment to be loaded, a 1- to 
6-character radix-5@ name, occupying two words. 


The following parameters are optional: 


I/O-status the address of the I/O status doubleword. 
Standard QIO status codes apply. 


AST-trp the address of an asynchronous’ trap service 
routine to which control is transferred at the 
completion of the load request. 


The condition code C is set or cleared on return, as follows: 


If the condition code C = @, the load request was successfully 
executed. 


If condition code C = 1, the load request was unsuccessful. 


For a synchronous load request, the return of the condition code 86 
Means that the desired segment has been loaded and is ready to be 
executed. For an asynchronous load request, the return of the code 9g 
means that the load request has been successfully queued to the device 
driver, but the segment is not necessarily in memory. The user must 
ensure that loading has been completed by waiting for the specified 
event flag before calling any routines or accessing any data in the 
segment. 


6.2.2 FORTRAN Subroutine for Manual Load Request 

To use manual load in a FORTRAN program, the program makes’ explicit 
reference to the SLOAD routine by means of the “MNLOAD’ subroutine. 
The subroutine call has the following form: 


CALL MNLOAD (seg-name,event-flag,I/O-status,ast-trp,ld-ind) 


where: 

seg-name is a 2 word real variable containing the segment name 
in radix-50 format. 

event-flag is an optional integer event flag number, to be used 


for an asynchronous load request. If the event flag 
number is zero, the load request is considered 
synchronous. 
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I/O-status is an optional 2-word integer array to contain the I/0 
status doubleword, as described for the QIO directive 
in the RSX-11D Executive Reference Manual. 


ast-trp is an optional asynchronous trap subroutine to be 
entered at the completion of a request. MNLOAD 
requires that all pending traps specify the same 
subroutine. 


1d-ind is an optional integer variable to contain the results 
of the subroutine call. One of the following values is 
returned: 
+l request was successfully executed. 


-l1 request had bad parameters or was not executed 
successfully. 


Optional arguments can be omitted. The following calls are all legal: 


Call Effect 
CALL MNLOAD (SEGA1) Load segment named in SEGAI1 
synchronously 
CALL MNLOAD (SEGA1,9,,,LDIND) Load segment named in  SEGAI1 
synchronously and return 


success indicator to LDIND. 
CALL MNLOAD (SEGA1,1,I1OSTAT,ASTSUB,LDIND) 


Load segment named in SEGAI1 
asynchronously, transferring 


control to ASTSUB upon 
completion of the load 
request, storing the 
I/O-status doubleword in 
IOSTAT and the success 


indicator in LDIND 


Consider the program CNTRL discussed in connection with the autoload 
method, and suppose that between the calls to the overlay segments 
there is sufficient processing to make asynchronous loading effective. 
The user removes the autoload indicators from his ODL description and 
recompiles his FORTRAN programs with explicit calls to the MNLOAD 
subroutine, as follows: 


PROGRAM CNTRL 

EXTERNAL ASTSUB 

DATA SEGA] /6RA1 f 

DATA SEGA21 /6RA21 / 

CALL MNLOAD (SEGA1,1,IOSTAT,ASTSUB,LDIND) 
CALL Al 


CALL MNLOAD (SEGA21,1,IOSTAT,ASTSUB,LDIND) 
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CALL A21 


END 
SUBROUTINE ASTSUB 
DIMENSION IOSTAT (2) 


END 


When the AST trap routine is given as shown in the preceding example, 
the IO status doubleword is automatically supplied to the dummy 
variable IOSTAT. 


6.3 ERROR HANDLING 


If the manual load method is selected, the user must provide error 
handling routines which diagnose load errors and provide appropriate 
recovery. 


If the autoload method is selected, a simple recovery procedure is 
provided, which checks the Directive Status Word (DSW) for the 
presence of an error indication. If the DSW indicates that no system 
dynamic storage is available, the routine issues a ‘wait for 
significant event’ directive and tries again; if the problem is not 
dynamic storage, the recovery procedure generates a breakpoint 
synchronous trap. If the using routine is set to service the trap and 
returns without altering the state of the program, the request can be 
retried. 


A more comprehensive user-written error recovery subroutine can _ be 
substituted for the system-provided routine if the following 
conventions are observed: 


1. The error recovery routine must have the entry point name 
SALERR. 


2. The contents of all registers must be saved and restored. 


On entry to SALERR, R2 contains the address of the segment descriptor 
that could not be loaded. Before recovery action can be taken, the 
routine must determine the cause of the error by examining the 
following words in the sequence indicated: 


1. SDSW - The Directive Status Word may contain an error 
status code, indicating that the I/O request to 
load the overlay segment was rejected by the 
Executive. 


2. N.OVPT - The contents of this location, offset by N.IOST, 
point to a 2-word I/O Status block containing the 
results of the load overlay request returned by 
the device driver. The status code occupies the 
low-order byte of word @. 
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6.4 EXAMPLE: CALC;5 


Suppose the task CALC is now complete and checked out and the user 
wants to adjust the autoload vectors to minimize the amount of storage 
required. 


From his knowledge of the flow of control of the task he can determine 
that PROC3 is always in memory as a result of path-loading when it is 
called and therefore, the autoload vector for PROC3 can be eliminated. 


The ODL description in CALTR, is modified as follows: 


-ROOT RDIN-RPRT-ADTA- (*PROC1,*PROC2, P3FCTR) 
P3FCTR: -FCTR PROC3-* (SUB1,SUB2) 
- END 


The task is built and the resulting memory allocation file in Figure 
6-1 shows that the repositioning of the autoload indicator saved 19 
bytes. 


FILE CALC.TSK;5 MEMORY ALLOCATION MAP 
THIS ALLOCATION WAS DONE ON 31~-MAR-75 
AT 15:58 BY TASK BUILDER VERSION RQ9 


***x RDOT SEGMENT: RDIN 


R/W MEM LIMITS: 9889080 036047 0368598 
STACK LIMITS: 990908 0990777 801900 
DISK BLK LIMITS: 988003 000041 098037 
IDENTIFICATION : $FORT 

PRG XFR ADDRESS: 681980 

TASK ATTRIBUTES: FP,NF 


PROGRAM SECTION ALLOCATION SYNOPSIS: 


<. BLK.>: @91000 921647 929650 
<ADTA >: 621658 923311 981442 
<DTA >: 023312 824753 901442 
<SFIOF >: @24754 @26733 981760 
<SFIOI >: 026734 827337 900404 
<SFIOL >: 927340 827348 BB00BD 
<$FIO1] >: 827348 931867 801530 
<SFIO2 >: 831978 831125 969636 
<SSALER>: 931126 @31151 960024 
<SSAOTS>: 031152 932075 880724 
<SSAUTO>: 932876 832231 969134 
<SSDEVT>: 932232 833441 991218 
<SSFSR1>: 933442 034461 801020 
<SSFSR2>: 934462 034563 909102 
<SSIOB1>: 934564 034767 800204 
<SSIOB2>: 934778 834778 8080008 
<S$SOBF1>: 834776 035077 900119 
<SSOBF2>: 9351880 835108 990000 
<SSOVCT>: 835188 835353 880254 
<SSOVDT>: GGBB0H BHDBBH BHHRBO 
<$SRESL>: 8035354 @35673 080320 
<. ABS.>: O000808 BBHHBH BB0HBD 


Figure 6-1 
Root Segment of Memory Allocation 
File for CALC;5 


CHAPTER 7 


SHAREABLE GLOBAL AREAS 


RSX-11D provides the facility for dynamic shareable global areas. 
This chapter describes the use and creation of shareable global areas 
in so far as they are related to task building. 


Shareable global areas have the following characteristics. 


l. They are created in a manner similar to tasks (i.e., with the 
Task Builder). 


2. There are two types of shareable global areas. 
Read-only known (by convention) as libraries. 
Read/write known (by convention) as common blocks. 


3. They occupy memory only when a referencing task is active. 
When all referencing tasks become inactive, the space 
occupied by shareable global areas is freed. Further, if the 
area being released was read/write, the data in the area are 
written back to the disk file from which the original loading 
occurred. 


4. When a task binds to a shareable global area, the area must 
exist in the form of a task image and symbol table file (.TSK 
and .STB extensions are required) under the system UFD [1,1], 
on the system device. 


5. At the time the binding task is to be installed, the 
shareable global area must have been installed. 


6. The /LI and /CM switches of Install are used to specify the 
shareable global area as a library or common block. 


Consider the first case, in which two tasks, Task A and Task B, need 
to communicate a large amount of data. A convenient method of 
transporting this data is the use of a shareable global area. Tasks 
can communicate independent of their time of execution. This case is 
illustrated by the following diagram: 
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Shareable Shareable 
Global Area Global Area 
Ss 


Resident Resident 
Executive Executive 


System Memory (System Memory) 
(Time t) Time ttn 


Task A and Task B communicate through the shareable global area, to 
which any number of tasks can be linked. 


Consider the second case, in which tasks make use of common routines. 
The common subroutines are not included in each task image; instead, 
they are included in a shareable global area so that a single copy is 
accessible to all tasks. This case is shown in the following diagram: 


ek eee 


Resident 
Executive 


Resident 
Executive 


System Memory System Memory 


A task can link to as many as seven shareable global areas (SGA). If, 
however, the task is multi~user and has read-only sections in the 
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root, this pure area of the root is considered as an SGA, and the 
number of external SGA’s which can be linked to the task is reduced to 
six. 


A shareable global area has associated with it a task image file and a 
symbol definition file. When a task links to a shareable global area 
the Task Builder uses the symbol definition file of the shareable 
global area to establish the linkages between the task and the 
shareable global area. 


7.1 USING AN EXISTING SHAREABLE GLOBAL AREA 


The user can link to any of the system shareable global areas by 
specifying the COMMON or LIBR keyword option along with the name of 
the shareable global area and the type of requested access. 


If the user wants to link task IMGl to a system shareable global area 
named JRNAL so relevent data can be examined, the following COMMON 
keyword entry is used to specify the name JRNAL and_ read-only 
attribute. 


MCR>TKB 
TKB>IMG1,LP:=IN1,IN2,IN3 
TKB>/ 

ENTER OPTIONS: 
TKB>COMMON=J RNAL : RO 
TKB>// 


A task can link to any shareable global area on the disk. However, 
before the task can be activated, any shareable global area it uses 
must be installed. These areas are loaded dynamically. 


7.2 CREATING A SHAREABLE GLOBAL AREA 


To create a shareable global area, the task image and symbol 
definition files must be built under UFD [1,1] on the system device. 


In Chapter 4, runnable tasks were described. A shareable global area 
differs from a runnable task in that it does not have a header or a 
stack. Therefore, the user must specify that the header and stack are 
not to be produced for the task image file when a shareable global 
area is created. These two parameters are necessary and sufficient to 
identify the entity as a shareable global area to both the Task 
Builder and Install. 


In summary, to create a shareable global area the following steps are 
taken: 


® The task image file and symbol definition file are built 
under UFD [1,1] on the system device. 


e The task image file or symbol definition file has the switch 
/-HD, indicating that no header is required. 
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e The option STACK=@ is entered during option input to 
eliminate the stack. 


8 Although it is not mandatory, the user can save disk space 
by setting UNITS = @. 


Suppose the user wants to create a resident library, ZETA, from’ the 
files 2Z1, 22, and 23. He builds the shareable global area, as 
follows: 


MCR>TKB 

TKB>[1,1] ZETA/-HD,LP: ,SY: [1,1] ZETA=Z1,22,23 
TKB>/ 

ENTER OPTIONS: 

TKB>STACK=8 

TKB>UNITS=9@ 

TKB>// 


A task can now link to the shareable global area. However, before the 
task can be installed and activated, the shareable global area must be 
made known to the Executive via Install, defining the owner, non-owner 
access and the type of SGA. The following example illustrates a 
typical installation procedure (see Install command in RSX-11D User's 
Guide). 


MCR>INS [1,1] ZETA/LI/UIC=[1,1] /ACC=RO 


7.3 POSITION INDEPENDENT AND ABSOLUTE SHAREABLE GLOBAL AREAS 


A shareable global area can be either position independent or 
absolute. Position independent shareable global areas can be placed 
anywhere in the task’s virtual address space. Absolute areas must be 
fixed in the virtual address space. 


The user must ensure that the area is position independent, if he 
applies the PI switch. The PI switch directs the Task Builder to 
treat the area as position independent, but the Task Builder can not 
determine whether or not the area is position independent. If the PI 
Switch is applied to an area which is not truly position independent, 
the execution of a task linked to that area is unpredictable. 


Data is always position independent: Code can be position 
independent, but the code produced as a result of compiling a FORTRAN 
program is not position independent. Furthermore, FORTRAN programs 


can not be used as shareable global areas because these programs do 
not satisfy the re-entrancy requirements necessary for shareable 
global areas. Refer to the RSX-11 MACRO-11 Reference Manual for 
further discussion of position independent coding. 


FORTRAN common blocks can be included in shareable global areas. 
However, the only way FORTRAN programs can communicate through the use 
of common blocks is by the common block name; to retain this name, 
the shareable global area must be declared position independent. If 
the area is not declared position independent, the name is not 
retained and no FORTRAN program can link to the common block. 


SHAREABLE GLOBAL AREAS 


Absolute shareable global areas are used for code which satisfies’ the 
re-entrancy requirements for a shareable global area but is not 
position independent. The BASE or TOP options are used to build such 
images. Non-PIC shareable global areas can reference PIC shareable 
global areas, but PIC shareable global areas cannot reference non-PIC 
shareable global areas. 


7.4 EXAMPLE: CALC;6 BUILDING AND USING A SHAREABLE GLOBAL AREA 


Suppose the task CALC has been completely debugged and the user wants 
to replace the dummy reporting routine RPRT by a generalized reporting 
program that operates as a separate task. This generalized reporting 
program GPRT was developed by another programmer in parallel with the 
development of CALC. Now both routines are ready and the user wants 
to create a shareable global area so that the two tasks can 
communicate. 


In addition to creating the shareable global area, the user must 
modify his FORTRAN routine to replace the call to the dummy reporting 
routine by a call to REQUEST for the task GPRT and he must remove’ the 
dummy routine from the ODL description for the task. 


7.4.1 Building the Shareable Global Area 


The common block into which CALC places its results and from _ which 
GPRT takes it input is named DTA. The user wants to make DTA into a 
shareable global area so that the two tasks can communicate. 


The user first creates a separate input file for DTA: 


MCR>EDI 
EDI>DTA.FTN 


[EDI -- CREATING NEW FILE] 
INPUT 


GLOBAL COMMON AREA FOR ‘CALC’ AND 
REPORTING TASK “GPRT’ 

BLOCK DATA 

COMMON /DTA/ A(208) ,I 

END 

*EX 


AA 


He then compiles DTA: 
MCR>FOR DTA,LP:=DTA 


Then the user builds the task image and symbol definition file for the 
shareable global area DTA: 


MCR>TKB 

TKB>[1,1]DTA/PI,LP:/SH,SY@: [1,1]DTA/-HD=DTA 
TKB>/ 

ENTER OPTIONS: 


| 
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TKB>STACK=@ 
TKB>UNITS=@ 
TKB>// 


The task image file for DTA is marked as position independent in order 
to retain the name of the referenced common block, DTA. 


As required, the task image and symbol definition files are created on 
the system device under the User File Directory [1,1,], the switch -HD 
is applied to the symbol definition file to specify that the task has 
no header, the option STACK=@ is entered to eliminate the stack, and @ 
logical units are specified. It was necessary to specify the system 
device SY®@ for the symbol definition file; if the user does not 
specify a device, the last named device applies. In this case, 
failure to specify the system device would have resulted in the 
application of the device specification LP to the symbol definition 
file. 


The shareable global area DTA now exists on the disk as an eligible 
candidate for inclusion in an active system. The user can now modify 
the task to link to that shareable global area. However, before the 
task can be executed, the shareable global area must be installed. 


7.4.2 Modifying the Task to Use the Shareable Global Area 


The user now modifies the task CALC. The file containing the program 
RDIN is edited to include the name of the reporting task in radix-5@ 
format: 


DATA RPTSK/6RGPRT / 


And the call to the dummy reporting routine RPRT is replaced by the 
call: 


CALL REQUES (RPTSK) 
The relevant part of the program RDIN is shown below: 


Cc READ AND ANALYZE INPUT DATA 

C ESTABLISH COMMON DATA BASE 
COMMON /DTA/ A(200), I 

C SET UP NAME OF REPORTING TASK IN RADIX 590 
DATA RPTSK /6RGPRT / 

C READ IN RAW DATA 
CALL REQUES (RPTSK) 


END 


The user now modifies the ODL description of the task CALC to remove 
the file RPRT.OBJ. The .ROOT directive is changed from: 


-ROOT RDIN-RPRT-ADTA- (*PROC1,*PROC2,P3FCTR) 


SHAREABLE GLOBAL AREAS 


-ROOT RDIN-ADTA- (*PROC1,*PROC2,P3FCTR) 
Then, an indirect command file is built to include the COMMON keyword: 


MCR>EDI 

EDI>CALCBLD.CMD 

[EDI -- CREATING NEW FILE] 
INPUT 

CALC, LP: /SH=CALTR/MP 
PAR=PAR14K 

ACTFIL=1 

COMMON=DTA: RW 

Es 

* EX 


| 


And the task is built, with the single command referencing the indirect 
file: 


MCR>TKB @CALCBLD 


The communication between the two tasks, CALC and GPRT, is now 
established. When the shareable global area DTA is made resident, the 
two tasks can run. 


7.4.3 The Memory Allocation Files 


Figure 7-l gives the memory allocation file for the shareable global 
area DTA. The attribute list indicates that the task image was built 
with no header (NH) and is position independent (PI). 


Figure 7-2 gives the memory allocation file for the task CALC after 
the shareable global area DTA was created and the dummy reporting 
routine removed from the task. The read-write memory limits for the 
root segment code have increased due to the call to REQUES. The 
read-write memory limits for the entire task have decreased because 
the common block DTA is now a shareable global area allocated at 
160800 and no longer part of the task. 


FILE DTA.TSK;1 MEMORY ALLOCATION MAP 
THIS ALLOCATION WAS DONE ON 31-MAR-75 
AT 15:54 BY TASK BUILDER VERSION RO9 


*** ROOT SEGMENT: DTA 


R/W MEM LIMITS: @88000 901443 901444 
DIS BLK LIMITS: 908082 800603 880002 
IDENTIFICATION: 

TASK ATTRIBUTES:FP,NF,PI,NH 


PROGRAM SECTION ALLOCATION SYNOPSIS: 
<. BLK.>: 980000 B0BB0H BHBHGD 


<DTA >: OO80088 861441 001442 
<. ABS.>: 908008 BOBHHH BHBHBD 


Figure 7-1 
Memory Allocation File for the Shareable Global Area DTA 


V fot 4 


SHAREABLE GLOBAL AREAS 


FILE CALC.TSK:6 MEMORY ALLOCATION MAP 
THIS ALLOCATION WAS DONE ON 31-MAR-75 
AT 16:28 BY TASK BUILDER VERSION R#9 


*** ROOT SEGMENT: RDIN 


R/W MEM LIMITS: 900000 034613 634614 
STACK LIMITS: 998009 O80777 081080 
DISK BLK LIMITS: 990083 089048 089036 
IDENTIFICATION : SFORT 
PRG XFR ADDRESS: 901009 
TASK ATTRIBUTES: FP,NF 


PROGRAM SECTION ALLOCATION SYNOPSIS: 


<. BLK.>: 681900 922057 921969 
<ADTA >: 922068 823521 881442 
<DTA >: 1690060 161441 961442 
<SFIOF >: 923522 925501 9801768 
<SFIOI >: 925502 926195 880404 
<SFIOL >: 926196 8026186 B8BBD 

<SFIO] >: 926196 627635 991530 
<SFIO2 >: 027636 827673 080036 
<SSALER>: 927674 927717 6090024 
<SSAOTS>: 927728 930643 000724 
<SSAUTO>: 938644 0380777 808134 
<SSDEVT>: 931808 832207 991219 
<SSFSR1>: 832218 6033227 9891020 
<SSFSR2>: 833230 033331 008102 
<$$IOB1>: 833332 633535 608284 
<$SIOB2>: 833536 833536 BOBDBD 
<$SOBF1>: 933536 033645 098119 
<SSOBF2>: 833646 833646 BOBGDD 
<S$$SOVCT>: 933646 834121 600254 
<SSOVDT>: BHB0008 BBV0HH BOBHBO 
<SSRESL>: 834122 934441 0903290 
<. ABS.>: B980808 ODHBOLHH BHBBHO 


FIGURE 7-2 
Memory Allocation File for CALC;6 


APPENDIX A 


ERROR MESSAGES 


The Task Builder produces diagnostic and fatal error messages. Error 
messages are printed in the following forms: 


TKB -- *DIAG*-error-message 
Or 
TKB -- *FATAL*-error-message 
Some errors are dependent upon correction from the terminal. If the 


user is entering text at the terminal, a diagnostic error message can 
be printed, the error corrected, and the task building sequence 
continued. If the same error is detected by the Task Builder in an 
indirect file, the Task Builder cannot request correction and thus the 
error is termed fatal and the task build is aborted. 


Some diagnostic error messages are simply informative and advise the 
user of an unusual condition. If the user considers the condition 
normal to his task, he can install and run the task image. 

This appendix tabulates the error messages produced by the _ Task 
Builder. Most of the error messages are self-explanatory. The Task 
Builder prints the text shown in this manual in upper case letters. 
In some cases, the Task Builder prints the line in which the error 


occurred, so that the user can examine the line which caused the 
problem and correct it. 


Q. ILLEGAL GET COMMAND LINE ERROR 
System error. (no recovery.) 


ni COMMAND SYNTAX ERROR 
invalid-line 


The invalid-line printed has incorrect syntax. 
2. REQUIRED INPUT FILE MISSING 


At least one file is required for a task build. 


10. 
ll. 


12. 


iS. 


ERROR MESSAGES 


ILLEGAL SWITCH 
invalid-line 


The invalid line printed contains an illegal switch or switch 
value. 


NO DYNAMIC STORAGE AVAILABLE 

The Task Builder needs additional symbol table storage and 
cannot obtain it. The input has exceeded the Task Builder’s 
capability. 

ILLEGAL ERROR/SEVERITY CODE 

System error. (No recovery.) 


COMMAND I/O ERROR 


I/O error on command input device. (Device may not be online 
or possible hardware error.) 


INDIRECT FILE OPEN FAILURE 
invalid-line 


The invalid-line contains a reference to a command input file 
which could not be located. 


INDIRECT COMMAND SYNTAX ERROR 
invalid-line 


The invalid-line printed contains a syntactically incorrect 
indirect file specification. 


MAXIMUM INDIRECT FILE DEPTH EXCEEDED 
invalid-line 


The invalid-line printed gives the file reference that 
exceeded the permissible indirect file depth (2). 


I/O ERROR ON INPUT FILE file-name 
OPEN FAILURE ON FILE file-name 
SEARCH STACK OVERFLOW ON SEGMENT segment-name 


The segment segment-name is more than 16 branch segments from 
the root segment. 


PASS CONTROL OVERFLOW AT SEGMENT segment-name 


The segment segment-name is more than 16 branch segments from 
the root segment. 


14. 


15. 


16. 


17. 


6. 


19. 


20. 


215 


22. 


ERROR MESSAGES 


FILE file-name HAS ILLEGAL FORMAT 


The file file-name contains an object module whose format is 
not valid. 


MODULE module-name AMBIGUOUSLY DEFINES P-SECTION p-sect-name 


The p-section p-sect-name has been defined in two modules not 
on a common path and referenced ambiguously. 


MODULE module-name MULTIPLY DEFINES P-SECTION p-sect—name 


1. The p-section p-sSect-name has been defined in the same 
segment with different attributes. 


2. A global p-section has been defined in more than one 
segment along a common path with different attributes. 


MODULE module-name MULTIPLY DEFINES XFR ADDR IN SEG 
segment-—name 


This error occurs when more than one module comprising the 
root has a start address. 


MODULE module-name ILLEGALLY DEFINES XFR ADDRESS p-sect-—name 
addr 


The module module-name is in an overlay segment and has a 
start address. The start address must be in the root segment 
of the main tree. 


P-SECTION p-sect-name HAS OVERFLOWED 
A section greater than 32K has been created. 
MODULE module~name AMBIGUOUSLY DEFINES SYMBOL sym-name 


Module module-name references or defines a symbol sym-name 
whose definition cannot be uniquely resolved. 


MODULE module-name MULTIPLY DEFINES SYMBOL sym-name 


Two definitions for the relocatable symbol sym-name have 
occurred on a common path. Or two definitions for an 
absolute symbol with the same name but different values. have 
occurred. 


SEGMENT seg~-name HAS R-O SECTION 
An attempt has been made to allocate a read-only p-section in 


an overlay segment. The build continues with R-W attribute 
forced. 


23% 


24. 


25. 


26. 


27. 


28. 


29. 


30. 


31. 


32. 


ERROR MESSAGES 


SEGMENT seg-name HAS ADDR OVERFLOW: ALLOCATION DELETED 
Within a segment, the program has attempted to allocate more 
than 32K. A map file is produced, but no task image file is 
produced. 

ALLOCATION FAILURE ON FILE file-name 

The Task Builder could not acquire sufficient contiguous disk 
space to store the task image file. (If possible, delete 
unnecessary files on disk to make more room available.) 

I/O ERROR ON OUTPUT FILE file-name 

This error may occur on any of the three output files. 


LOAD ADDR OUT OF RANGE IN MODULE module-name 


An attempt has been made to store data in the task image 
outside the address limits of the segment. 


TRUNCATION ERROR IN MODULE module-name 

An attempt has been made to load a global value greater’ than 
+127 or less than -128 into a byte. The low-order eight bits 
are loaded. 


number UNDEFINED SYMBOLS SEGMENT seg-name 


The Memory Allocation File lists each undefined symbol by 
segment. 


INVALID KEYWORD INDENTIFIER 
invalid-line 


The invalid-line printed contains an unrecognizable keyword. 


OPTION SYNTAX ERROR 
invalid-line 


The invalid-line printed contains unrecognizable syntax. 


TOO MANY PARAMETERS 
invalid-line 


The invalid-line printed contains a keyword with more 
parameters than required. 


ILLEGAL MULTIPLE PARAMETER SETS 
invalid-line 


The invalid-line printed contains multiple parameters for a 
keyword which only allows a single parameter. 


33% 


34. 


33% 


36. 


37. 


38. 


39:5 


4Q. 


41. 


42. 


ERROR MESSAGES 


INSUFFICIENT PARAMETERS 
invalid-line 


The invalid-line contains a keyword with an insufficient 
number of parameters to complete the keyword meaning. 


TASK HAS ILLEGAL MEMORY LIMITS 


An attempt has been made to build a task whose size exceeds 
the partition boundary. 


OVERLAY DIRECTIVE HAS NO OPERANDS 
invalid-line 


All overlay directives except .END require operands. 


ILLEGAL OVERLAY DIRECTIVE 
invalid-line 


The invalid-line printed contains an unrecognizable overlay 
directive. 


OVERLAY DIRECTIVE SYNTAX ERROR 
invalid-line 


The invalid-line printed contains a syntax error. 


ROOT SEGMENT MULTIPLY DEFINED 
invalid-line 


The invalid-line printed contains the second .ROOT directive 
encountered. Only one .ROOT directive is allowed. 


LABEL OR NAME IS MULTIPLY DEFINED 
invalid-line 


The invalid-line printed contains a name that has already 
appeared on a .FCTR, .NAME, or .PSECT directive. 


NO ROOT SEGMENT SPECIFIED 
The overlay description did not contain a .ROOT directive. 


BLANK P-SECTION NAME IS ILLEGAL 
invalid-line 


The invalid-line printed contains a .PSECT directive that 
does not have a p-section name. 


ILLEGAL P-SECTION ATTRIBUTE 
invalid-line 


The invalid-line printed contains a p-section attribute that 
is not recognized. 


43. 


44, 


45. 


46. 


47. 


48. 


49. 


5@. 


51. 


52. 


ERROR MESSAGES 


ILLEGAL OVERLAY DESCRIPTION OPERATOR 
invalid-line 


The invalid-line printed contains an unrecognizable operator 
in an overlay description. 


TOO MANY NESTED .ROOT/.FCTR DIRECTIVES 
invalid-line 


The invalid-line printed contains a .FCTR directive that 
exceeds the maximum nesting level (32). 


TOO MANY PARENTHESES LEVELS 
invalid-line 


The invalid-line printed contains a parenthesis that exceeds 
the maximum nesting level (32). 


UNBALANCED PARENTHESES 
invalid-line 


The invalid-line printed contains unbalanced parentheses. 
ILLEGAL BASE OR TOP ADDRESS OFFSET 


The task is too large to fit into the space allowed by BASE= 
or TOP= keywords. 


ILLEGAL LOGICAL UNIT NUMBER 
invalid-line 


The invalid-line printed contains a device assignment to a 
unit number larger than the number of logical units specified 
by the UNITS keyword or assumed by default if the UNITS 
keyword is not used. 


ILLEGAL NUMBER OF LOGICAL UNITS 
invalid-line 


The invalid-line printed contains a number of logical unit 
greater than 2580. 


ILLEGAL NUMBER OF ACTIVE FILES SPECIFIED 


ILLEGAL BASE OR TOP BOUNDARY VALUE 
invalid line 


ILLEGAL POOL USAGE NUMBER SPECIFIED 
invalid line 


The pool request is greater than 255 or it iS zero. 


53% 


54. 


55. 


56. 


57. 


58. 


59. 


60. 


61. 


ERROR MESSAGES 


ILLEGAL DEFAULT PRIORITY SPECIFIED 
invalid-line 


The invalid-line printed contains a priority greater than 
250. 


ILLEGAL ODT OR TASK VECTOR SIZE 
SST vector size specified greater than 32 words. 


ILLEGAL FILENAME 
invalid-line 


The invalid-line printed contains a wild card (*) in a file 
specification. The use of wild cards is prohibited. 


ILLEGAL DEVICE/VOLUME 
invalid line 
The device/volume string is too long. 


LOOKUP FAILURE ON FILE filename 
invalid-line 


The invalid-line printed contains a filename which cannot be 
located in the directory. 


ILLEGAL DIRECTORY 
invalid-line 


The invalid-line printed contains an illegal UFD. 
INCOMPATIBLE REFERENCE TO A LIBRARY P-SECTION p-sect-—name 

A task has attempted to reference more storage in a shareable 
global area than exists in the shareable global area 
definition. 

ILLEGAL REFERENCE TO LIBRARY P~SECTION p-sect-—name 

A task has attempted to reference a p-sect-name existing in a 
resident library (shareable global area) but has not named 


the library in a COMMON or LIBR keyword. 


RESIDENT LIBRARY MEMORY ALLOCATION CONFLICT 
keyword-string 


One of the following problems has occurred: 


1. More than three shareable global areas have been 
specified. 


2. The same shareable global area has been specified more 
than once. 


3. Shareable global areas whose memory allocations overlap 


62. 


63. 


64. 


65. 


66. 


67. 


68. 


69. 


76. 


71. 


72. 


ERROR MESSAGES 


have been specified. 
4. BASE or TOP specifications conflict. 


LOOKUP FAILURE RESIDENT LIBRARY FILE 
invalid-line 


No symbol table or task image file found for the’ shareable 
global area on SY@ under UFD [1,1]. 


INVALID ACCESS TYPE 
invalid-line 


Requested access to shareable global area was not RW or RO. 


ILLEGAL PARTITION/COMMON BLOCK SPECIFIED 
invalid-line 


User defined base or length not on 32 word bound or user 
defined length = @. 


NO MEMORY AVAILABLE FOR LIBRARY library-name 


Insufficient virtual memory available to cover total memory 
needed by referenced shareable global areas. 


PIC LIBRARIES MAY NOT REFERENCE OTHER LIBRARIES 
invalid-line 


ILLEGAL APR RESERVATION 


APR specified on COMMON or LIBR keyword that is outside the 
range @-7. 


I/O ERROR LIBRARY IMAGE FILE 


An I/O error has occurred during an attempt to open or _ read 
the Task Image File of a shareable global area. 


LIBRARY REFERENCES UNDEFINED LIBRARY 


A shareable global area specified by LIBR or COMMON 
references another area which is undefined. 


not used. 
INVALID APR RESERVATION 


APR specified on a LIBR or COMMON keyword for an_ absolute 
shareable global area. 


COMPLEX RELOCATION ERROR - DIVIDE BY ZERO: MODULE 
module-name 


A divisor having the value zero was detected in a complex 
expression. The result of the divide was set to zero. 
(Probable cause- division by an undefined global symbol.) 


73. 


74. 


75. 


76. 


77. 


78. 


79. 


88. 


81. 


ERROR MESSAGES 


WORK FILE I/O ERROR 

I/O error during an attempt to reference data stored by the 
Task Builder ina work file. Possibly an attempt to extend 
the file when no more space is available on the volume. 
LOOKUP FAILURE ON SYSTEM LIBRARY FILE 


The Task Builder cannot find the system Library 
(SY@:[1,1]SYSLIB.OLB) file to resolve undefined symbols. 


UNABLE TO OPEN WORK FILE 


Work file device is not mounted or has not been initialized 
as Files-ll, or there is no space on the volume. 


NO VIRTUAL MEMORY STORAGE AVAILABLE 


Maximum permissible size of the work file exceeded (no 
recovery). 


MODULE module-name NOT IN LIBRARY 


The Task Builder could not find the module named on the LB 
switch in the library. 


INCORRECT LIBRARY MODULE SPECIFICATION 
invalid-line 


The invalid-line contains a module name with a non~Radix-5@ 
character. 


LIBRARY FILE filename HAS INCORRECT FORMAT 


A module has been requested from a library file that has an 
empty module name table. 


RESIDENT LIBRARY IMAGE HAS INCORRECT FORMAT 
invalid-line 


The invalid-line specifies a shareable global area that has 
one of the following problems: . 


1. The library file image has a header. 

2. The shareable global area references another’ shareable 
global area with invalid address bounds (i.e., not on 4K 
boundary). 


3. The shareable global area has invalid address bounds. 


PARTITION partition-name HAS ILLEGAL MEMORY LIMITS 


The user has attempted to build a privileged task whose 
length exceeds 16K. 


82. 


83. 


84. 
85. 


ERROR MESSAGES 
not used 


ABORTED VIA REQUEST 
input-line 


The input-line contains a request from the user to abort 
task build. 


not used 
END OF FILE REACHED BEFORE .END DIRECTIVE IN file-name 


The overlay description file named in this message does 
contain a .END directive as required. 


A-10 


the 


not 


APPENDIX B 


TASK BUILDER DATA FORMATS 


An object module is the fundamental unit of input to the Task Builder. 


Object modules are created by any of the standard language processors 
(i.e., MACRO-11, FORTRAN, etc.) or the Task Builder itself (symbol 
definition file). The RSX-11D librarian (LBR) provides the ability to 
combine a number of object modules together into a single library 
file. 


An object module consists of variable length records of information 
that describe the contents of the module. Six record (or block) types 
are included in the object language. These records guide the Task 
Builder in the translation of the object language into a task image. 
The six record types are: 


Type 1 - Declare Global Symbol Directory (GSD) 


Type 2 End of Global Symbol Directory 
Type 3 - Text Information (TXT) 
Type 4 ~ Relocation Directory (RLD) 


Type 5 


Internal Symbol Directory (ISD) 


Type 6 - End of Module 


Each object module must consist of at least five of the record types. 
The one record type that is not mandatory is the internal symbol 
directory. The appearance of the various record types in an object 
module follows a defined format. See Figure B-l. 


An object module must begin with a Declare GSD record and end with an 
end-of~module record. Additional Declare GSD records may occur 
anywhere in the file but before an end-of-GSD record. An end-of-GSD 
record must appear before the end-of-module record. At least one 
relocation directory record must appear before the first text 
information record. Additional relocation directory and text 
information records may appear anywhere in the file. The internal 


TASK BUILDER DATA FORMATS 
symbol directory records may appear anywhere in the file between the 
initial declare GSD and end-of-module records. 
Object module records are variable length and are identified by a 


record type code in the first word of the record. The format of 
additional information in the record is dependent upon the record 


type. 

Initial GSD 

Initial Relocation Directory 
Additional GSD 

Text Information 

Text Information 


Relocation Directory 


GSD Additional GSD 
END GSD End of GSD 


Internal Symbol Directory 


Internal Symbol Directory 
Text Information 


Text Information 


Text Information 


END OF MODULE 


END MODULE 


Figure B-1 
General Object Module Format 


B.1 GLOBAL SYMBOL DIRECTORY (GSD) 


Global symbol directory records contain all the information necessary 
to assign addresses to global symbols and to allocate the memory 
required by a task. 


GSD records are the only records processed in the first pass, thus 
Significant time can be saved if all GSD records are placed at the 
beginning of a module (i.e., less of the file must be read in phase 


3). 


TASK BUILDER DATA FORMATS 


GSD records contain seven types of entries: 


Type 
Type 
Type 
Type 
Type 
Type 


Type 


3 


> 


6 


Each entry type is 


first two words 


Module Name 

Control Section Name 

Internal Symbol Name 

Transfer Address 

Global Symbol Name 

Program Section Name 

Program Version Identification 


represented by four words in the GSD 
contain six Radix-5@ characters. 


contains a flag byte and the entry type identification 
word contains additional information about the entry. 


VALUE 


Figure B-2 
GSD Record And Entry Format 


record. The 
The third word 
‘ The fourth 
See Figure B-2. 


TASK BUILDER DATA FORMATS 


B.1.1 Module Name 
The module name entry declares the name of the object module. The 
name need not’ be unigue with respect to other object modules (i.e., 


modules are identified by file not module name) but only one_ such 
declaration may occur in any given object module. See Figure B-3. 


MODULE 
a Mea ae 


Figure B-3 
Module Name Entry Format 


B.1.2 Control Section Name 
Control sections, which include ASECTs, blank-CSECTS, and named-CSECTs 
are supplanted in RSX-11D by PSECTs. For compatibility, the Task 
Builder processes ASECTs and both forms of CSECTs. Section B.1.6 
details the entry generated for a PSECT statement. In terms of a 
PSECT statement we can define ASECT and CSECT statements as follows: 
For a blank CSECT, a PSECT is defined with the following attributes: 
-PSECT ,LCL,REL,CON,RW,I,LOW 
For a named CSECT, The PSECT definition is: 
»-PSECT name, GBL,REL,OVR,RW,1I,LOW 
For an ASECT, The PSECT definition is: 
»-PSECT .ABS.,GBL,ABS,I,OVR,RW, LOW 
ASECTs and CSECTs are processed by the Task Builder as PSECTs with the 


fixed attributes defined above. The entry generated for a control 
section is shown in Figure B-4. ; 


CONTROL SECTION 


NAME 


1 IGNORED 


MAXIMUM LENGTH 


Figure B-4 
Control Section Name Entry Format 


TASK BUILDER DATA FORMATS 


B.1.3 Internal Symbol Name 


The internal symbol name entry declares the name of an internal symbol 
(with respect to the module). TKB does not support internal symbol 
tables and therefore the detailed format of this entry is not defined 


(Figure B-5). If an internal symbol entry is encountered while’ 
reading the GSD, it is merely ignored. 


ae ae 
UNDEFINED 


Figure B-5 
Internal Symbol Name Entry Format 


B.1.4 Transfer Address 


The transfer address entry declares the transfer address of a module 
relative to a P-section. The first two words of the entry define the 
name of the P-section and the fourth word the relative offset from the 
beginning of that P-section. If no transfer address is declared in a 
module, a transfer address entry either must not be included in the 
GSD or a transfer address of 960001 relative to the default absolute 
P-section (. ABS.) must be specified. See Figure B-6. 


SECTION 
ian 
OFFSET 


Figure B-6 
Transfer Address Entry Format 


NOTE 


If the P-section is absolute, 
then OFFSET is the actual 
transfer address if not 
OOG0G1. 


TASK BUILDER DATA FORMATS 


B.1.5 Global Symbol Name 

The global symbol name entry (Figure B-7) declares either a global 
reference or a definition. All definition entries must appear after 
the declaration of the P-section under which they are defined and 
before the declaration of another P-section. Global references may 
appear anywhere within the GSD. 

The first two words of the entry define the name of the global symbol. 
The flag byte declares the attributes of the symbol and the fourth 
word the value of the symbol relative to the P-section under which it 
is defined. 


The flag byte of the symbol declaration entry has the following bit 
assignments. 


Bits @ - 2 - Not used. 


Bit 3 - Definition 
9 = Global symbol references. 


1 = Global symbol definition. 
Bit 4 — Not used 


Bit 5 - Relocation 
8 = Absolute symbol value. 


1 = Relative symbol value 


Bit 6 - 7 - Not used. 


SYMBOL 
NAME 
Ml a canal FLAGS 
VALUE 


Figure B-7 
Global Symbol Name Entry Format 


B.1.6 Program Section Name 


The P-section name entry (Figure B-8) declares the name of a P-section 


TASK BUILDER DATA FORMATS 


and its maximum length in the module. It also declares the attributes 
of the P-section via the flag byte. 


GSD records must be constructed such that once a P-section name has 
been declared all global symbol definitions that pertain to that 
P-section muSt appear before another P-section name is declared. 
Global symbols are declared via symbol declaration entries. Thus the 
normal format is a P-section name followed by zero or more_ symbol 
declarations, the next P-section name followed by zero or more symbol 
declarations, and so on. 


The flag byte of the P-section entry has the following bit 
assignments: 


Bit @ - Memory Speed 
8 = P-section is to occupy low speed (core) memory. 


1 = P~section is to occupy high speed (i.e., MOS/Bipolar) memory. 


Bit 1 - Library P-section 
@ = Normal P-section. 


1 = Relocatable P-section that references a shareable global area. 


Bit 2 - Allocation 
0 = P-section references are to be concatenated with other 
references to the same P-section to form the total memory 
allocated to the section. 
1 = P-section references are to be overlaid. The total memory 


allocated to the P-section is the largest request made by 
individual references to the same P-section. 


Bit 3 ~ Not used but reserved. 


Bit 4 - Access 
@ = P-section has read/write access. 


1 - P-section has read-only access. 


Bit 5 - Relocation 
@ = P-section is absolute and requires no relocation. 
1 = P-section is relocatable and references to the control section 


must have a relocation bias added before they become 
absolute. 
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Bit 6 


Scope 


®@ = The scope of the P-section is local. References to the same 
P-section will be collected only within the segment in which 
the P-section is defined. 


1 = The scope of the P-section is_ global. References to the 
P-section are collected across segment boundaries. The 
segment in which a global P-section is allocated storage is 
determined either by the first module that defines the 
P-section on a path or by direct placement of a P-section in 
a segment via the Overlay Description Language .PSECT 
directive. 


Bit 7 


Type 
@ = The P-section contains instruction (I) references. 


1 = The P-section contains data (D) reference Identification 


P-SECTION 
NAME 
PLAGS 
MAX LENGTH 


Figure B-8 
P-Section Name Entry Format 


NOTE 


The length of all absolute sections is 
zero. 


B.1.7 Program Version Identification 


The program version identification entry (Figure B-9) declares’ the 
version of the module. TKB saves the version identification of the 
first module that defines a nonblank version. This identification is 
then included on the memory allocation map and is written in the label 
block of the task image file. 


The first two words of the entry contains the version identification. 
The flag byte and fourth words are not used and contain no meaningful 
information. 
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SYMBOL 
NAME 


Figure B-9 
Program Version Identification Entry Format 


B.2 END-OF-GLOBAL-SYMBOL—DIRECTORY 


The end-of-global-symbol-directory record (Figure B-1%) declares’ that 
no other GSD records are contained further on in the file. Exactly 
one end-of-GSD-record must appear in every object module and is one 


word in length. 
oe 2 


Figure B-19 
End Of GSD Record Format 


B.3 TEXT INFORMATION 


The text information record (Figure B-1l1) contains a byte string of 
information that is to be written directly into the task image file. 
The record consists of a load address followed by the byte string. 


Text records may contain words and/or bytes of information whose final 
contents are yet to be determined. This information will be bound by 
a relocation directory record that immediately follows the text record 
(see Section B.4). If the text record does not need modification, 
then no relocation directory record is needed. Thus multiple text 
records may appear in sequence before a relocation directory record. 


The load address of the text record is specified as an offset from the 
current P-section base. At least one relocation directory record must 
precede the first text record. This directory must declare the 
current P-section. 


TKB writes a text record directly into the task image file and 
computes the value of the load address minus four. This value is 
stored in anticipation of a subsequent relocation directory that 
modifies words and/or bytes that are contained in the text record. 
When added to a relocation directory displacement byte, this value 
yields the address of the word and/or byte to be modified in the task 
image. 
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ae ee 
LOAD ADDRESS 
TEXTQ TEXT 


TEXT 


Figure B-1l 
Text Information Record Format 


B.4 RELOCATION DIRECTORY 
Relocation directory records (Figure B-12) contain the information 
necessary to relocate and link a preceding text information record. 
Every module must have at least one relocation directory record that 
precedes the first text information record. The first record does not 
modify a preceding text record, but rather it defines the current 
P-section and location. Relocation directory records contain 13 types 
of entries. These entries are classified as relocation or location 
modification entries. The following types of entries are defined: 

Type 1 - Internal Relocation 

Type 2 - Global Relocation 

Type 3 - Internal Displaced Relocation 

Type 4 - Global Displaced Relocation 

Type 5 - Global Additive Relocation 


Type 6 - Global Additive Displaced Relocation 


B-10 
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Type 7 - Location Counter Definition 

Type 18 - Location Counter Modification 

Type 11 - Program Limits 

Type 12 - P-Section Relocation 

Type 13 - Not used 

Type 14 - P-Section Displaced Relocation 

Type 15 - P-Section Additive Relocation 

Type 16 - P-Section Additive Displaced Relocation 

Type 17 - Complex Relocation 
Each type of entry is represented by a command byte (specifies type of 
entry and word/byte modification), a displacement byte, and the 
information required for the particular type of entry, in that order. 
The displacement byte, when added to the value calculated from the 
load address of the previous text information record, (see Section 
G.3) yields the virtual address in the image that is to be modified. 


The command byte of each entry has the following bit assignments. 


Bits @ - 6 Specify the type of entry. Potentially 128 command types 
may be specified although only 15(decimal) are implemented. 


Bit -— 7 Modification 
@ = The command modifies an entire word. 


1 


The command modifies only one byte. The Task Builder’ checks 
for truncation errors in byte modification commands. If 
truncation is detected (i.e., the modification value has a 
Magnitude greater than 255), an error is produced. 
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Figure B-12 
Relocation Directory Record Format 
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B.4.1 Internal Relocation 


This type of entry (Figure B-13) relocates a direct pointer to an 
address within a module. The current P-section base address is added 
to a specified constant and the result is written into the task image 
file at the calculated address (i.e., displacement byte added to value 
calculated from the load address of the previous text block). 


Example: 

A: MOV #A,RO 
or 
- WORD A 


DIsE pe} 
CONSTANT 


Figure B-13 
Internal Relocation Command Format 


B.4.2 Global Relocation 
This type of entry (Figure B-14) relocates a direct pointer to a 
global symbol. The definition of the global symbol is obtained and 


the result is written into the task image file at the calculated 
address. 


Example: 
MOV #GLOBAL ,R@ 
or 


- WORD GLOBAL 


a ee 
SYMBOL 
NAME 


Figure B-14 
Global Relocation 
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B.4.3 Internal Displaced Relocation 


This type of entry (Figure B-15) relocates a relative reference to an 
absolute address from within a relocatable control sectiion. The 
address plus 2 that the relocated value is to be written into is 
subtracted from the specified constant. The result is then written 
into the task image file at the calculated address. 


Example: 
CLR 177550 
or 
MOV 177558,RO 


Disp eae 
CONSTANT 


Figure B-15 
Internal Displaced Relocation 


B.4.4 Global Displaced Relocation 


This type of entry (Figure B-16) relates a relative reference to a 
global symbol. The definition of the global symbol is obtained and 
the address plus 2 that the relocated value is to be written into 
is subtracted from the definition value. This value is then written 
into the task image file at the calculated address. 


Example: 
CLR GLOBAL 
Or 
MOV GLOBAL ,R@ 


wee] 
SYMBOL 
NAME 


Figure B-16 
Global Displaced Relocation 
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B.4.5 Global Additive Relocation 
This type of entry (Figure B-17) relocates a direct pointer to a 
global symbol with an additive constant. The definition of the global 
symbol is obtained, the specified constant is added, and the resultant 
value is then written into the task image file at the calculated 
address. 
Example: 

MOV #GLOBAL+2,RQ@ 

Or 


-WORD GLOBAL-4 


CONSTANT 


Figure B-17 
Global Additive Relocation 


B.4.6 Global Additive Displaced Relocation 


This type of entry (Figure B-18) relocates a relative reference to a 
global symbol with an additive constant. The definition of the global 
symbol is obtained and the specified constant is added to _ the 
definition value. The address plus 2 that the relocated value is to 
be written into is subtracted from the resultant additive value. The 
resultant value is then written into the task image file at the 
calculated address. 


Example: 
CLR GLOBAL+2 
or 
MOV GLOBAL-5 ,R®@ 


SYMBOL 
NAME 


CONSTANT 


Figure B-18 
Global Additive Displaced Relocation 
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B.4.7 Location Counter Definition 


This type of entry (Figure B-19) declares a current P-section and 
location counter value. The control base is stored as the current 
control section and the current control section base is added to the 
specified constant and stored as the current location counter value. 


ee ee 
SECTION 
NAME 

CONSTANT 


Figure B-19 
Location Counter Definition 


B.4.8 Location Counter Modification 


This type of entry (Figure B-29) modifies the current location 
counter. The current P-section base is added to the specified 
constant and the result is stored as the current location counter. 


Example: 


ae ees 


CONSTANT 


Figure B-29 
Location Counter Modification 
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B.4.9 Program Limits 


This type of entry (Figure B-21) is generated by the .LIMIT assembler 
directive. The first address above the header (normally the beginning 
of the stack) and highest address allocated to the tasks are obtained 
and written into the task image file at the calculated address and at 
the calculated address plus 2 respectively. 


Example: 


- LIMIT 


fe 


Figure B-21 
Program Limits 


B.4.18 P-Section Relocation 


This type of entry (Figure B-22) relocates a direct pointer to the 
beginning address of another P-section (other than the P-section in 
which the reference is made) within a module. The current base 
address of the specified P-section is obtained and written into the 
task image file at the calculated address. 


Example: 
~-PSECT A 
B: 
PSECT Cc 
MOV #B,RO 
or 
- WORD B 


posse] a 
SECTION 
NAME 


Figure B-22 
P-Section Relocation 
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B.4.11 P-Section Displaced Relocation 


This type of entry (Figure B-23) relocates a relative reference to the 
beginning address of another P-section within a module. The current 
base address of the specified P-section is obtained and the address 
plus 2 that the relocated value is to be written into is subtracted 
from the base value. This value is then written into the task image 
file at the calculated address. 


Example: 
-PSECT A 

B: 
~-PSECT C 
MOV B,RO 


pIsP fa} a | 


SECTION 
NAME 


Figure B-23 
P-Section Displaced Relocation 


B.4.12 P-Section Additive Relocation 


The type of entry (Figure B-24) relocates a direct pointer to an 
address in another P-section within a module. The current base 
address of the specified P-section is obtained and added to the 
specified constant. The result is written into the task image file at 
the calculated address. 
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Example: 
-PSECT A 
B: 
Cs < 
PSECT D 
MOV #B+10,RO 
MOV #C,RO 
or 


- WORD B+19 
-WORD Cc 


psp af as | 


SECTION 
NAME 
CONSTANT 


Figure B-24 
P-~Section Additive Relocation 


B.4.13 P-Section Additive Displaced Relocation 


This type of entry (Figure B-25) relocates a relative reference to an 
address in another P-section within a module. The current base 
address of the specified P-section is obtained and added to _ the 
specified constant. The address plus 2 that the relocated value is to 
be written into is subtracted from the resultant additive value. This 
value is then written into the task image file at the calculated 
address. 
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Example: 
~-PSECT A 
B: 
Cs : 
-PSECT D 
MOV B+19,R@ 
MOV C,RO 


psp] ae 


SECTION 
NAME 
CONSTANT 


Figure B-25 
P-Section Additive Displaced Relocation 


B.4.14 Complex Relocation 

This type of entry (Figure B-26) resolves a complex relocation 
expression. Such an expression is one in which any of the MACRO-11 
binary or unary operations are permitted with any type of argument, 
regardless of whether the argument is unresolved global, relocatable 
to any P-section base, absolute, Or a complex relocatable 
subexpression. 


The RLD command word is followed by a string of numerically-specified 
operation codes and arguments. All of the operation codes occupy one 
byte. The entire RLD command must fit in a single record. The 
following operation codes are defined. 

8 - No operation 

1 - Addition (+) 

2 - Subtraction (-) 

3 - Multiplication (*) 

4 - Division (/) 


5 - Logical AND (&) 


TASK BUILDER DATA FORMATS 


6 - Logical inclusive OR (!) 
18 - Negation (-) 
11 - Complement (“C) 
12 - Store result (command termination) 
13 - Store result with displaced relocation (command termination) 


16 - Fetch global symbol. It is followed by four bytes containing 
the symbol name in RADIX-59@ representation. 


17 - Fetch relocatable value. It is followed by one byte 
containing the sector number, and two bytes containing the 
offset within the sector. 


28 - Fetch constant. It is followed by two bytes containing the 
constant. 


The STORE commands indicate that the value is to be written into’ the 
task image file at the calculated address. 


All operands are evaluated as 16-bit signed quantities using two’s 
complement arithmetic. The results are equivalent to expressions that 
are evaluated internally by the assembler. The following rules are to 
be noted. 


1. An attempt to divide by zero yields a zero result. The task 
Builder issues a nonfatal diagnostic. 


2. All results are truncated from the left in order to fit into 
16 bits. No diagnostic is issued if the number was too 
large. If the result modifies a byte, the Task Builder 
checks for truncation errors. 


3. All operations are performed on relocated (additive) or 
absolute 16-bit quantities. PC displacement is applied to 
the result only. 
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Example: 
~-PSECT ALPHA 
A: 


-PSECT BETA 


MOV #A+B-G1/G2&<7C<177120!G3>>,R1 


Cor fo] fl 
COMPLEX STRING 


Figure B-26 
Complex Relocation 


B.5 INTERNAL SYMBOL DIRECTORY 


Internal symbol directory records (Figure B-27) declare definitions of 
symbols that are local to a module. This feature is not supported by 
TKB and therefore a detailed record format is not specified. If TKB 
encounters this type of record, it will ignore it. 


EM 


NOT 
SPECIFIED 


Figure B-27 
Internal Symbol Directory Record Format 


B.6 END OF MODULE 


The end-of-module record (Figure B-28) declares the end-of-an object 


module. Exactly one end of module record must appear in each object 
module and is one word in length. 


Figure B-28 
End-Of-Module Record Format 
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TASK IMAGE FILE STRUCTURE 


The task image as it is recorded on the disk appears in Figure C-l. 


BLOCK 


OVERLAY 


OVERLAY SEGMENT 


WLLL BED SPACE YL 


BLOCK 


BLOCK 


SS 


CO-TREE ROOT SEGMENT 


VES BCE YL 


OVERLAY SEGMENT 
BLOCK 


MMU he 


OVERLAY SEGMENT 
BLOCK 


R-O ROOT SEGMENT 
BLOCK BOUNDARY 


re yuo task §—§ WALL DSBS ULL 


BLOCK 


4K VIRTUAL ADDRESS 
BOUNDARY AND 32-WORD 
REAL ADDRESS BOUNDARY 


4K VIRTUAL ADDRESS 
BOUNDARY AND 32-WORD 
REAL ADDRESS BOUNDARY 


BLOCK TASK VIRTUAL ADDRESS @ 


OMITTED IF /-HD 
VARIABLE WITH /TA, 
/FP AND N 


BLOCK 


4N BYTES (N=NO. LUNS) 
I.E., @, 1, 2 BLOCKS 


BLOCK 


BLOCK 
VIRTUAL BLOCK 1 
BLOCK 


Figure C-l 
Task Image on Disk 
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C.1 LABEL BLOCK GROUP 


The label block group, shown in Figure C-2, precedes the task on _ the 
disk, and contains data that need not be resident during task 
execution, and up to two blocks containing device assignment data for 
LUNs 1-255. The task label blocks (first block in group) are read and 
verified by Install. The information in these blocks is used to fill 
in the task header. 


LABEL 

LSBTSK 0 
2 

LSBPAR 4 DEFAULT PARTITION 
6 


NAME 


LSBDAT 24 CREATION YEAR 
26 DATE OF 
=== TASK 
30 DAY 
LS$BLIB 32 
LIBRARY NAME 
34 
36 LENGTH IN 32-WORD BLOCKS 
40 CREATION YEAR oie : 
42 DATE OF REQUEST 


44 
46 
50 


SIX MORE LIBRARY REQUESTS 


LSBHRB 212 VIRTUAL BLOCK NO. OF HEADER 
L$BAPR 214 LIBRARY STARTING APR NUMBER 
LSBEXT 216 TASK EXTENSION INCREMENT 


PROTOTYPE PAGE 


LSBPDR 220 DESCRIPTOR REGISTERS 
Q-7 
PROTOTYPE PAGE 
LS$BASR 240 ADDRESS REGISTERS 


g-7 


L$BUIC 260 TASK UIC 


*Shareable Global Area 


‘Figure C-2 
Label Block Group 


BLOCK 


BLOCK 
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DIRECTORY ID 


DEVICE NAME 


DEVICE NAME 
UNIT NUMBER 


DEVICE NAME 
UNIT NUMBER 


DEVICE NAME 


UNIT NUMBER 


DEVICE NAME 
UNIT NUMBER 


Figure C-2 (Cont.) 
Label Block Group 


LUN 127 


LUN 128 


LUN 255 
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C.1.1 Label Block Details 


The information contained in the label block is verified by the 
Install task in creating a system task directory (STD) entry for the 
task, and in linking the task to shareable global areas. 


LSBTSK Task name, consisting of two words in Radix-59@ format. 
The value of this parameter is set by the TASK keyword. 


LSBPAR Partition name, consisting of two words in Radix-5@ 
format. Its value is set by the PAR keyword. 


LSBFLG Task flag word containing bit values that are set or 
cleared depending on defined task attributes. 
Attributes are established by appending the appropriate 
Switches to the task image file specification. 


Bit Attribute if Set=1 

SF.MU 6 Task is multi-user (/MU) 

SF.PT 7 Task is privileged (/PR) 

SF.XA 11 Task is not abortable (/-AB) 

SF.XD 12 Task is not disableable (/-DS) 

SF.XF 13 Task is not fixable (/-FX) 

SF.XC 14 Task is not checkpointable (/-CP) 
LSBPRI Default priority, set by the PRI keyword. 
LSBLDZ Load size of the task, expressed in multiples of 


32-word blocks. The value of LSBLDZ is equal to the 
Size of the root segment, in multi-segment tasks. 


LSBMXZ Maximum size of the task, expressed in multiples of 
32-word blocks. The header size is included. 


LSBMXZ is used by Install to verify that the task fits 
into the specified partition. 


LSBPOL Pool usage limit indicating maximum number of pool 
nodes that can be used simultaneously by the task. The 
default is 48 (decimal) which is overridden by the POOL 


keyword. 
LSLFLG Flags word for the image of a shareable global area. 
Bit Interpretation if Set=1 
LFSPIC 4) Image is position independent (/PI) 
LFSNHD 1 Image has no header (/-HD) 
LSBDAT Three words, containing the task creation date as 


2-digit integer values, as follows: 


YEAR (since 199@) 
MONTH OF YEAR 
DAY OF MONTH 
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The following paragraphs describe components of the Shareable Global 
Area Name Block. An 8-word block is generated for each shareable 
global area referenced by the task. Because shareable global areas 
need not be resident in the system, the Task Builder builds the block 
from the area’s disk image, using information in the label blocks of 
that image. 


Library Name A 2-word Radix-5@ name specified in the LIBR or 
COMMON keyword. 


Creation Date Obtained from the creation date in the shareable 
global area disk image label block. 


Starting Address First address used to map the Shareable Global Area 
into the task addressing space. 


Flag Word Bits 2 and 15 are used as follows: 
Bit Value Meaning 


LDSREL 2 1 Global area is PIC.set if value 
of LFSPIC in the library image 
flags word (LSFLG) is =l. 


O Global area is absolute. 
Cleared if LFSPIC in LSLFLG of 
global area image is @. 


LDSACC 15 1 Read/Write access request. Set 
if RW specified in LIBR or 
COMMON option. 


O Read-only ACCESS request. 
Cleared if RO specified in LIBR 
or COMMON option. 


LSBHRB Virtual block number of the task header. Between 2 and 
4 depending on number of LUNS, as follows: 


UNITS = @ virtual block 2 
UNITS = 1-128 virtual block 3 
UNITS = 129-255 virtual block 4 


LSBAPR Starting APR number if this image is a shareable global 
area. Calculated from BASE or TOP keywords. 


LSBEXT The default number of words by which the memory 
allocated to a task at install time will be increased. 
This value is overridden by INSTALL/INC keyword. Value 
is set with EXTTSK keyword of TKB. 


LSBPDR The eight prototype page descriptor registers for the 
task. INSTALL copies these into task header where 
necessary modifications can be performed. 


LSBASR The eight prototype page address registers for the task. 
INSTALL copies these into the task header where 
necessary modifications can be performed. 
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LSBUIC The UIC with which the task is built. Set by UIC 
keyword. 


Since the R/W and R-O parts of the root segment are each contiguous 
blocks on the disk, each can be loaded with a single disk read. If 
the task is not multi-user, only a single read is required. 


C.2 HEADER 


The task is read into main memory starting at the base of the Header. 
Figure C-3 illustrates the format of the fixed part. As shown in 
Figure C-l, the variable part consists of the Logical Unit Table, 
Floating Point Save Area and the Task Accounting Work Area. The 
Logical Unit Table identifies to the Executive which device is 
assigned to which LUN. The Floating Point Save Area is storage for 
the PDP-11/45 floating point registers when this option is requested. 
The task accounting work area is used by the Executive if accounting 
is enabled. 


The Header is always a multiple of 32-word blocks. This insures’ that 
the root segment code starts on a 32-word boundary, a requirement for 
the allocation of a APR pair of relocation registers. The Task Header 
is not covered by a task relocation register, and is therefore, not 
part of the virtual address space of the task. 


NOTE 


Privileged tasks may access the Header 
via symbolic offsets, which are obtained 
by linking the file EXEC.STB. Executive 
defined symbolic offsets are indicated 
in the figure, to the right of the 
corresponding Header element and Task 
Builder reference labels are those to 
the left. The real load address of a 
task header can be found from the tasks 
Active Task List entry. 


LABEL 

HSDFLP 9 

HSDPDR 2 

26 

HSDPAR _ 
HSDPWA 
HSDPS 
HSDPC 
HSDR@ ~—s«6G 
HSDR1 7p 
HSDR2 72 
HSDR3 74 
HSDR4 76 
HSDR5 19 
HSDSP 12 
HSDIPS 194 
HSDPIC 196 
HSDISP 119 
HSDDSV_ 112 
HSDTSV 114 
HSDTVT 416 
HSDDVT 
HSDPHN 129 
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FLOATING POINT SAVE POINTER 


INSTALL TIME 


PAGE DESCRIPTOR REGISTERS 


a ee ee -— oo 


INSTALL TIME 
> PAGE 
ADDRESS 


REGISTERS 


TASK SST VECTOR ADDRESS 
TASK VECTOR LENGTH 


Figure C-3 
Task Header Fixed Part 


OFFSETS 


H.CR1 


H.PD@ 


H.PD7 


H.PAG 


H.PA7 


H. PW 


H.TPS 
H.TPC 


H.TSP 
H.ISP 
H.IPC 


H.ISP 


H.DSV 
H.TSV 
H.DV7 
H.PUN 


H.CR2 


(116) H.TVZ (117) 
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LABEL OFFSETS 
vs = 
15 


*Used only by handler tasks but reserved in all. 


Figure C-3 (Cont.) 
Task Header Fixed Part 
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C.2.1 Logical Unit Table Entry 


Each entry in the Logical Unit Table has the form shown in Figure C-4. 


PUD POINTER 
WINDOW BLOCK POINTER 


Figure C-4 
Logical Unit Table Entry 


The first word contains the address of the device physical unit 
directory (PUD) in the Executive system tables that contains device 
dependent information. 


The second word is a pointer to the window block if the device is 
file-structured. 


The PUD address is set at install-time if a corresponding ASG 
parameter is specified at task-build-time. This word can also be set 
at run-time with the Assign Lun Directive to the Executive and is 
modified by the re-assign MCR function. 


The window block pointer is set when a file is opened on the device 
whose PUD address is specified by word 1. The window block pointer is 
cleared when the file is closed. 


C.2.2 Floating Point Save Area 


If a task is built with the FP attribute, 25 (decimal) words are 
allocated in the header immediately following the Logical Unit Table. 
A pointer to this area is set in the fixed part of the header at 
offset H.CRI1. The Executive uses this area to save and restore the 
registers of the PDP 11/45 floating point unit upon context switching. 


C.2.3 Task Accounting Work Area 


If a task is built accountable (with the TA switch), 1698 (decimal) 
words are allocated following the floating point save area. A pointer 
(ASR 3 relative) is stored in the fixed part of the header at offset 
H.AC. When the task is run in a system on which task accounting is 
enable, the Executive accumulates the pertinent accounting information 
in this area. 
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C.3 LOW MEMORY POINTERS 
Several locations at the beginning of a task’s virtual address space 
are reserved for system dependent information. These locations are as 
follows: 
Address (Virtual) Usage 
SDSW Directive Status Word. The Executive returns 


the completion code in this word for every 
system directive issued by the task. 


a 


2% »FSRPT File Control Services work area and buffer 
pointer. 
4. SOTSV FORTRAN OTS work area pointer (i.e., address 


of SOTSVA). 
6. N.OVPT Overlay Run Time system work area pointer. 


The last three of these locations contain addresses of work areas. 
These addresses are needed to provide reentrancey capability to the 
associated system routines when these areas are required by shareable 
global areas or multi-user tasks. 


Note that it is possible for a task to destroy these pointers if a 
stack overflow occurs. 


C.4. TASK R/W ROOT SEGMENT 


The low memory pointers, stack space and all R/W p-sections of the 
task root segment are concatenated by the Task Builder to form the R/W 
part of the root segment. 


Following the user specified p-sections, the Task Builder allocates 
space for the overlay run time system data base, which is described 
below. Finally the R/W area is rounded-up to a 32-word boundary for 
APR allocation. However, if the task is defined multi-user, a further 
rounding is performed. This time the R/W area is rounded to a _ block 
boundary. 


C.5 TASK R-O ROOT SEGMENT 


If the root segment of the task has R-O p~sections, the R-O p-sections 
are allocated contiguous space for mapping on a separate APR. 


Since the R-O root segment is the shareable global area of a 
multi-user task, it is loaded separately, and only once, by the 
Executive no matter how many versions of the task are _ invoked. 
Consequently, the R-O root segment must be on a block boundary for a 
multi-user task. 
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C.6 SEGMENT TABLES 


The Segment Table contains a segment descriptor for every segment in 
the task. The segment descriptor is formatted as shown in Figure C-5. 
If the autoload method is used, the segment descriptor is six words in 
length. If the manual load method is used, the segment descriptor is. 
expanded to be eight words in length to include the segment name. 


SEGMENT 
NAME 


Figure C-5 
Segment Descriptor 


C.6.1 Status 


The status bit is used in the autoload method to determine if an 
overlay is in memory, that is: 


bit 12 = @ segment is in memory. 


bit 12 


1 segment is not in memory. 


C.6.2 Relative Disk Address 


Each segment begins on a block boundary and occupies a contiguous disk 
area to allow an overlay to be loaded by a single device access. The 
relative disk address is the relative block number of the overlay 
segment from the start of the task image. The maximum relative block 
number can not exceed 4896 since twelve bits are allocated for the 
relative disk address. 
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C.6.3 Load Address 


The load address contains the address into which the loading of the 
overlay segment starts. 


C.6.4 Segment Length 


The segment length contains the length of the overlay segment in bytes 
and is used to construct the disk read. 


C.6.5 Link-Up 


The link-up is a pointer to a segment descriptor away from the root. 


C.6.6 Link-Down 


The link-down is a pointer to a segment descriptor nearer the root. 


C.6.7 Link-Next 
The link-next is a pointer to the adjoining segment descriptor. When 
a segment is loaded, the loading routine follows the link-next to 


determine if a Segment in memory is being overlaid and_ should 
therefore be marked out-of-memory. 


The link-next pointers are linked in a circular fashion: 


Consider the tree: 


A21 A22 
Al A2 


A2l A22 A2l A22 A21 A22 
L Eevee — 
Al A2 Al A2 Al A2 


no ad o> 


link up link down link next 
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If there is a co-tree, the link-next of the segment descriptor for the 
root points to the segment descriptor for the root segment of the 
co-tree. 


C.7 AUTOLOAD VECTORS 


Autoload vectors appear in every segment that references autoload 
entry points in segments that are farther from the root than the 
referencing segment. 


The autoload vector table consists of one entry per autoload entry 
point in the form shown in Figure C-6. 


JSR PC 
SAUTO 


SEGMENT DISCRIPTOR ADDR. 
ENTRY POINT ADDRESS 


Figure C-6 
Autoload Vector Entry 


C.8 OVERLAY SEGMENTS 


Each overlay segment begins on a block boundary. The relative block 
number for the segment is placed in the segment table. Note that a 
given overlay segment occupies as many contiguous disk blocks as it 
needs. to supply its space request - the maximum size for any segment, 
including the root, is 32K-32 words. 
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RESERVED SYMBOLS 


Several global symbol and p-section* names are reserved for use by the 
Task Builder. Special handling occurs when a definition of one of 
these names is encountered in a task image. 


The definition of a reserved global symbol in the root segment causes 
a word in the Task Image to be modified with a value calculated by the 
Task Builder. The relocated value of the symbol is taken as_ the 
modification address. 


The following global symbols are reserved by the Task Builder: 


GLOBAL MODIFICATION 

SYMBOL VALUE 

- MOLUN Error message output device. 

.NLUNS The number of logical units used by the task, not 
including the Message Output and Overlay units. 

. NOVLY The overlay logical unit number. 

»NSTBL The address of the segment description tables. Note 


that this location is modified only when the number of 
segments is greater than one. 


. TRLUN The trace subroutine output logical unit number. 

-ODTL1 Logical unit number for the ODT input device. 

-ODTL2 Logical unit number for the ODT output device. 

SOTSV The address in low memory of the FORTRAN OTS work area 


(SOTSVA defined by the FORTRAN OTS). 
The definition of a reserved p-section causes that p-section to be 


* P-sections are created by .ASECT, .CSECT, or .PSECT directives. The 
-PSECT directive obviates the need for either the .ASECT or .CSECT 
directives, these being retained for compatibility only. In this 
document all sections will be referred to as p-sections unless the 
specific characteristics of .ASECTS or .CSECT apply. Refer to RSX-1l 
MACRO-11 Reference Manual for additonal discussion of .ASECTS and 
-CSECT directives. 
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extended if the appropriate option input is specified (see section 


3.2.3.4). 


The following p-section names are reserved by the Task Builder: 


SECTION 
NAME 


SSDEVT 


S$SFSR1 


$SIOB1 


SSOBF1 


EXTENSION 
LENGTH 


The extension length (in bytes) is calculated from 
the formula 


EXT = <S.FDB+52>*UNITS 


Where the definition of S.FDB is obtained from the 
root segment symbol table and UNITS is the number 
of logical units used by the task, excluding the 
Message Output, Overlay , and ODT units. 


The extension of this section is specified by the 
ACTFIL option input. 


The extension of this section is specified by the 
MAXBUF option input. 


FORTRAN OTS uses this area to parse array type 
format specifications. May be extended by FMTBUF 
keyword. 
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CROSS REFERENCE TASK 


The RSX-11D Task Builder is capable of providing a global cross 
reference file in addition to its other files. A global cross 
reference is an alphabetical listing of all global symbols, their 
values, and the names of all modules that refer to them. The global 
cross reference is appended to the memory allocation map of the task 
by the cross reference utility. 


A global cross reference is requested by a Task Builder command string 
that includes the /CR_ switch with the memory allocation (MAP) file 
specification. The /CR switch causes the Task Builder to create two 
files: 


1. A .MAP file that is the traditional memory allocation file, 


2. A .CRF file that contains records to be processed by _ the 
cross reference task. 


Upon completion of a task build operation, the Task Builder issues a 
SEND AND REQUEST directive to the cross reference task to provide it 
with the name of its input (.CRF) file. 


The cross reference task processes the input file, appending its 
Output to the .MAP file of the same name under the same UFD. When the 
cross reference task has completed its processing, the .CRF input file 
is deleted. 


The cross reference task is an independent task having [11,1]CRF.TSK 
as a file name and CRF... as a task name. Therefore, the Task 
Builder or MCR reprompts at the terminal before the cross’ reference 
text has been completely appended to the memory allocation file. 


If the memory allocation file specification to the Task Builder 
includes both a /-SP switch to inhibit spooling and the /CR switch, 
the user should wait until the .CRF file has been deleted (that is, 
until the cross reference task has exited) before queuing the memory 
allocation file for printing. CRF appends the cross’ reference 
information to the memory allocation file. 
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INCLUDING A DEBUGGING AID 


If the user wants to include a program which controls the execution of 
the task he is building, he can do so by naming the appropriate object 
module as an input file and applying the /DA switch. 


When such a program is input, the Task Builder causes control to be 
passed to the program when the task execution is initiated. 


Such control programs might trace a task, printing out relevant 
debugging information, or monitor the task’s performance for analysis. 


The switch has the following effect: 


1. The transfer address in the debugging aid overrides the task 
transfer address. 


2. On initial task load, the following registers have’ the 
indicated value: 


R@ - Transfer address of task 
Rl - Task name in Radix-5@ format (word #1) 
R2 - Task name (word #2) 


The following points must be taken into consideration when uSing 
debugging aids on a task (particularly ODT): 


l. Breakpoints cannot be set in R-O p-Sections 


2. Care must be used if settings breakpoints in overlay 
branches. 
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RSX-11D TASK BUILDER GLOSSARY 


AUTOLOAD - 


CO-TREE 


GLOBAL SYMBOL - 


MAIN TREE - 


MANUAL LOAD - 


MEMORY ALLOCATION FILE - 


The method of loading overlay segments, in 
which the Overlay Runtime System 
automatically loads overlay segments when 
they are needed and handles any unsuccessful 
load requests. 


An overlay tree whose segments, including the 
root segment, are made resident in memory 
through calls to the Overlay Runtime System. 


A symbol whose definition is known outside 
the defining module. 


An overlay tree whose root segment is loaded 
by the Monitor when the task is made active. 


The method of loading overlay segments’ in 
which the user includes explicit calls in his 
routines to _ load overlays and handles 
unsuccessful load requests. 


The output file created by the Task Builder 
that describes the allocation of task memory. 


OVERLAY DESCRIPTION LANGUAGE - A language that describes’ the overlay 


OVERLAY 


OVERLAY 


OVERLAY 


OVERLAY 


RUNTIME SYSTEM - 


SEGMENT - 


STRUCTURE - 


TREE - 


structure of a task. 


A set of subroutines linked as part of an 
overlaid task that are called to _ load 
segments into memory. 


A segment that shares storage with other 
segments and is loaded when it is needed. 


A structure containing a main tree and 
optionally one or more co-trees. 


A tree structure consisting of a root segment 
and optionally one or more overlay segments. 


RSX-11M TASK BUILDER GLOSSARY 


PATH - 


PATH-DOWN - 


PATH-UP - 


PATH-LOADING - 


PRIVILEGED TASK - 


P-SECTION - 


ROOT SEGMENT - 


RUNNABLE TASK - 


SHAREABLE GLOBAL AREA - 


SEGMENT - 


SYMBOL DEFINITION FILE - 


TASK IMAGE FILE - 


A route that is traced from one segment in 
the overlay tree to another segment in that 
tree. 


A path toward the root of the tree. 
A path away from the root of the tree. 


The technigue used by the autoload method to 
load all segments on the path between a 
calling segment and a called segment. 


A task that has privileged memory access 
rights. A privileged task can access the 
Executive and the I/O page in addition to its 
own partition and referenced shareable global 
areas. 


A section of memory that is a unit of the 
total allocation. A source program is 
translated into object modules that consist 
of p-sections with attributes describing 
access, allocation, relocatability, etc. 


The segment of an overlay tree that, once 
loaded, remains in memory during the 
execution of the task. 


A task that has a header and stack and that 
can be installed and executed. 


Code and/or data bound together by the Task 
Builder, in such a way that tasks can be 
bound to them to reference data and/or 
routines by symbol. Many tasks can share one 
copy of such areas and the area is’ resident 
only when a referencing task is active. 


A group of modules and/or p-sections’ that 
occupy memory simultaneously and that can be 
loaded by a single disk access. 


The output file created by the Task Builder 
that contains the global symbol definitions 
and values in a format suitable for 
reprocessing by the Task Builder. Symbol 
definition files are used to link tasks to 
shared regions. 


The output file created by the Task Builder 
that contains the executable portion of the 
task. 
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VIRTUAL SYMBOL TABLE 


H.1 ADJUSTMENT AND PLACEMENT OF VIRTUAL MEMORY 


The symbol table constructed by the Task Builder is only part of a 


dynamic, virtual memory system. This virtual memory is partially 
resident and partially a disk workfile. The maximum size of this 
virtual memory is 65,534 words. The ratio of resident storage to 


workfile storage iS a parameter that can be adjusted by re-building 
the Task Builder. This can be done in RSX=-11D by altering the 
directive EXTSCT = FRSIZ1l: ..... in the build command file of the 
Task Builder. Note that the extension of this memory must not cause 
the Task Builder to become larger than the maximum size for any 
task - namely 32,736. (32K-32) words. 


Increasing the proportion of dynamic memory that is resident reduces 
the amount of I/O necessary for access to the Task Builder's internal 
data structures. Once the resident memory has been filled, the data 
structures overflow into a temporary work file on the device assigned 
to the workfile logical unit number. This logical unit number (WSLUN) 
is specified in the build command file; it may be advantageous to 
assign this unit number to a device other than the system device(e.g., 
a fixed head disk). 


Displacement of pages to the workfile is done on a least recently used 
basis. The workfile will be automatically extended as necessary to 
hold all pages displaced. The parameter WSKEXT is provided in the 
build command file of the Task Builder and defines the file extension 
properties. A negative value indicates that the extension is 
non-contiguous; a positive value indicates a contiguous extend. If 
the workfile remains contiguous, a higher access rate can be obtained; 
however, this is advisable only when it is known that contiguous space 
is always available. 


H.2 CONTENT OF VIRTUAL MEMORY 


It is not possible to state exactly how many symbols the Task Builder 
can process, because there are many data structures included in 
virtual memory. Following is a list of the structures that are stored 


VIRTUAL SYMBOL TABLE 


in the virtual memory. All the sizes given are approximations; the 
Size varies with the characteristics of the task being built and may 
vary from release to release of the operating system. 


Structure Description Approx. 

Name Size 
(WORDS ) 

Segment Descriptor Contains listheads 60. 


sizes, the pointers 
defining the overlay 
tree, the segment name, 
Part of this structure 
becomes the segment 
descriptor in the 
resultant task image. 


P-section descriptor Contains the name, 10. 
address, size and 
attributes of a 
p-section. 


Symbol Descriptor Contains symbol name, 8. 
value, flags and 
pointers to defining 
segment and p-section 
descriptors. 


Element Descriptor Contains module 8.-18. 
name, ident, filename, 
count of p-sections 
and some flags. 


The maximum usage of virtual memory occurs during phase three of the 
Task Builder, when the symbol table is built. However, phase one 
makes Significant use of virtual memory when an overlayed task is 
being built. It is at this point that all the segment descriptors are 
allocated and that element descriptors are allocated for each filename 
encountered during the parsing of the tree description. In addition, 
a P-section descriptor is produced for every .PSECT directive 
encountered in the overlay description. 


The parsing of the overlay description also makes use of dynamic 
memory during the processing of each directive. This memory is 
released upon completion of the analysis, but during the analysis, the 
whole tree description must fit into the resident portion of storage. 
If sufficient storage cannot be obtained in the resident dynamic 
memory, the error message 'NO DYNAMIC STORAGE AVAILABLE' is produced. 
The method of increasing the ratio of dynamic storage to virtual 
memory can be applied to allow a task with a large overlay description 
to be built. 


The amount of memory required during analysis depends on: 


1. Number of directives 
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2. Length of .FCTR lines 


3. Number of operators (i.e., commas, dashes, parentheses’~ and 
asterisks). 


4. Number of filenames encountered. 


The resident portion of the virtual memory specified on the _ released 
version of the Task Builder is sufficient to handle the overlay 
description file of the Task Builder itself, as well as Filex. These 
overlay descriptions are suggested as guidelines for constructing 
complex overlay trees. 


H.3 REDUCTION OF VIRTUAL MEMORY REQUIREMENTS 


There are a number of ways to reduce the amount of virtual memory 
required during the build of a specific task. Reduction of the data 
structures in virtual memory increases the speed of searching the 
tables and reduces the amount of paging to the workfile. The 
following metods will reduce virtual memory: 


1. Extraction of object modules by name (i.e., 
LIBRY/LB:MOD1,MOD2 type constructs) from relocatable object 
libraries. This technique requires smaller element 


Gescriptors and fewer filename descriptors; it is faster 
because there are fewer files to open and close. 


2. Use of concatenated object modules. 


3. Use of shareable global areas (resident libraries and common 
areas) for language and overlay run time systems and file 
control services. This means that symbols and P-sections are 
defined once rather than on multiple branches of the tree. 


4. Use of common segments. Modules that occur on _ parallel 
branches of the tree should be placed on a common (i.e., 
closer to root) segment for the same reasons as 3 above. 


5. Use of the /SS switch on symbol table files (.STB) that 
describe absolute symbol definition. This means that only 
those symbols that are referenced will be extracted from the 
module. 


6. Minimizing the number of segments and keeping the tree 
balanced. For example, if one segment is very long, there is 
no value in puting a tree structure in parallel unless 
creation of one segment in parallel would be longer. 
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H.4 ERROR MESSAGES 


There are four error messageS associated with the virtual memory 


system: 


Ls 


NO DYNAMIC STORAGE AVAILABLE. This error is produced when 
there is insufficient resident storage for creating a data 
structure. As much as possible (all unlocked pages) of the 
data already allocated has been paged to the workfile but 
there is still not enough free space in the resident area. 
Such a situation may arise during the analysis of the overlay 
description, early in the task build run and particularly if 
it is a complex tree. The recommended recovery procedures 
are to reduce the ODL and extend the Task Builder memory 
allocation. 


UNABLE TO OPEN WORKFILE. The probable causes of this error 
are: 


1. Device assigned to the logical unit WSKLUN of: the Task 
Builder does not have a volume mounted. 


2. The volume does not support FILES-1l. 

3. There is no space on the volume. 

4. The device is offline, not ready, write locked or faulty. 
5. There is no such device. 


The MCR function LUN ...TKB can be used to determine which 
device the Task Builder is attempting to uSe. 


WORKFILE I/O ERROR. The most probable causes of this error 
are: 


1. Hardware error - e.g., parity errors on the disk. 
2. Device is not ready, is dismounted or write locked. 


3. An extend failure has occurred (e.g., there is 
insufficient contiguous space in this area of the disk 
when WSKEXT is positive); the disk is full. In these 
cases, try allocating a contiguous 256 block file and 
deleting it just before running the task build. 


NO VIRTUAL MEMORY STORAGE AVAILABLE. The addressable limit 
of the virtual memory has been reached. There is no recovery 
other than to reduce the virtual memory requirements of the 
task being built. 
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ABORT, 3-13 
Abortable switch (AB), 3-3 
ABORT option, 3-13 
Absolute patch option (ABSPAT), 
3-22 
Absolute shareable global areas, 
7-4 
ABSPAT, 3-22 
ACTFIL, 3-15, 4-18 
Active files, 3-15 
Address, transfer, B-5 
Allocation file, memory, 1-2 
Allocation of p-sections, 4-5 
Allocation options, 3-15 
ACTFIL, 3-15 
BASE, 3-18 
EXTSCT, 3-16 
EXTTSK, 3-17 
FMTBUF, 3-16 
MAXBUF, 3-15 
POOL, 3-17 
STACK, 3-17 
TOP, 3-18 
Allowable switch codes, 3-1 
Attribute codes of task image, 
4-13 
Attributes, p-section, 4-3 
ASG, 3-21 
Assignment, device, 3-21 
Asynchronous loading, 6-8 
Autoload, 1-2, 6-2 
Autoload indicator, 6-2 
Autoload vectors, 5-14, 6-4, C-13 


BASE, 3-18 

Base address option (BASE), 3-18 

Building a shareable global area, 
7=5 

Building of task, 3-25 

Building task, 2-10, 5-16 

Buffer size, format, 3-16 

Buffer size, maximum record, 3-15 


C 


Code and data, 

R-O, 4-3 

R/W, 4-2 
Code, user identification, 2-8 
Checkpointable switch (CP), 3-3 


Commands, 2-1 

Command line, task, 2-2 

Command, task building, 2-11 

Comma operator, 5-11, 5-22 

Comment lines, 2-7 

COMMON, 3-19 

Common block, resident, 3-19 

Common blocks, 7-1 

Common routines, 7-2 

Compiling FORTRAN programs, 2-10 

Complex relocation, B-20 

Concatenated object modules, 3-3 

Concatenated object modules 
switches (CC), 3-3 

Content altering options, 3-13 

Control option, ABORT, 3-13 

Control options, 3-13 

Control section name, B-4 

Core image, overlay, 5-13 

Co-tree, 5-24 

Co-tree overlay region, 5-14 

Co-trees, use of, 5-10 

Creating a shareable global area, 
7-3 

Cross Reference Switch, 3-4 

Cross Reference Task, E-1l 


D 


Data and code, 
R-O, 4-3 
R/W, 4-2 
Dash (hyphen) operator, 5-7 
Data formats, task builder, B-1l 
Debugging aid, including a, F-1l 
Debugging aid switch (DA), 3-4 
Default assumption for switches, 
3-2 
Default assumptions in file 
specification, 2-14 
Default stack, 4-2 
Defaults, 1-1 
Defining multiple tree structure, 
5-11 
Description, segment, 4-15 
Descriptor, 
element, H-2 
p-section, H-2 
segment, H-2 
symbol, H-2 
Device, 2-13 
Device assignment option (ASG), 
3-21 
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Device specifying options, 3-20 File specification, default 
ASG, 3-21 assumptions in, 2-14 
UNITS, 3-20 File storage region, 4-17 
Diagnostic, exit on, 3-9 File structure, task image, C-l 
Directive, Files, memory allocation, 7-7 
EXTSCT =, H-1 Fixable switch (FX), 3-4 
-END, 5-7 Floating point save area, C-9 
-FCTR, 5-8 Floating point switch (FP), 3-4 
-NAME, 5-9 FMTBUF, 3-16 
-PSECT, 5-9 Format buffer size, (FMTBUF) 
-ROOT, 5=7 option, 3-16 
Directive status word, 4-2 FORTRAN common blocks, 7-4 
Directory, FORTRAN programs, 7-4 
end of global symbol, B-9 FORTRAN programs, compiling, 2-10 
global symbol, B-2 FORTRAN subroutine for manual 
internal symbol, B-22 load request, 6-7 


relocation, B-10 
Disable switch (DS), 3-4 


Disk address, relative, C-l1l G 
FE GBLDEF, 3-21 
GBLPAT, 3-22 
Global additive displaced 

EDI, text editor, 2-9 relocation, B-15 
Element descriptor, H-2 Global additive relocation, B-15 
-END directive, 5-7 Global displaced relocation, B-14 
End of global symbol directory, Global relative patch option 

B-9 (GBLPAT) , 3-22 
End of module, B-22 Global relocation, B-13 
Entering source language, 2-9 Global symbol definition option 
Error handling, 6-9 (GBLDEF), 3-21 
Error messages, A-1l Global symbol directory, B-2 
Existing shareable global area, Global symbol name, B-6 

using an, 7-3 Global symbols, 
Exit on diagnostic switch (XT), reserved, D-1l 

3-9 resolution of, 4-7 
Extend task space option (EXTTSK), Glossary, task builder, G-1 

3-17 Group, 2-14 
Extending memory, H-l GSD, B-2 


EXTSCT, 3-16, H-l 
EXTTSK, 3-17 


H 
F 


Header, C-6 
Header switch (HD), 3-5 
-FCTR directive, 5-8 Header, task, 4-2 
File, Hyphen operator, 5-22 
memory allocation, 4-9 
structure of memory allocation, 
4-12 I 
task image, 4-9 
File contents, 4-16 


File, memory allocation, 1-2, Identification options, 
5-16 PAR, 3-14 

Filename, 2-13 PRI, 3-14 

File, output, 2-12 TASK, 3-14 

File specification, 2-7 UIC, 3-14 
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Identification, program version, 
B-8 

Image file, task, 4-9 

Improving task builder 
performance, E-1l 

Impure area pointers, 4-2 

Including a debugging aid, F-1l 

Indirect command file facility, 
2-5 

Input line, 2-12 

Input, multiple line, 2-3 

Internal displaced relocation, 
B-14 

Internal relocation, B<«13 

Internal symbol directory, B-22 

Internal symbol name, B-5 

Interpretation of autoload 
indicator, 6-3 


L 


Label block details, C-4 
Label block group, C-2 
Label block size, C-5 
LIBR, 3-19 
Libraries, 7-1 
Library file switch (LB), 3-5 
Library, resident, 3-19 
Limits, program, B-17. 
Line, 
input, 2-12 
option, 2-12 
task command, 2-12 
Lines, comments, 2-7 
Link-down, C-12 
Link-next, C-12 
Link-up, C-12 
Load address, C-12 
Loading mechanism, 5-4 
Loading mechanisms, 6-1 
Load request, synchronous, 6-7 
Location counter definition, B-16 
Location counter modification, 
B-16 
Logical unit table entry, C-9 
Logical unit usage option (UNITS), 
3-20 
Low core contents, C-10 
Low memory pointers, C-10 


Manual load, 1-2, 6-1, 6-6 
Manual load calling sequence, 6-6 
MAXBUF, 3-16 


Maximum record buffer size 
(MAXBUF) , 3-15 
Member, 2-14 
Memory allocation, 4-1 
file, 1-2, 4-9, 5-16 
file, structure of, 4-12 
files, 7-7 
file, short, 3-7, 5-16 
Memory contents, virtual, H-1l 
Memory, extending, H-1l 
Memory requirements, reduction 
of virtual, H-3 
Memory, system, 4-8 
Memory, task, 4-1 
Messages, error, A-l 
Modification, location counter, 
B-16 
Modifying a task to use an SGA, 
7-6 
Module, end of, B-22 
Module name, B-4 
Multiple line input, 2-3 
Multiple task specification, 2-4 
Multiple tree, 5-11 
Multiple tree structure, defining, 
5-11 
Multiple tree structures, 5-10 
Multi-segment task, 5-4 
Multi-user switch (MU), 3-6 


Name, 
control section, B-4 
global symbol, B-6 
internal symbol, B-5 
module, B-4 
program section, B-6 
-NAME directive, 5-9 
Names, reserved p-section, D-l_. 
No dynamic storage available, H-4 
No virtual memory storage avail- 
able, H-4 
Number of Active Files option 
(ACTFIL), 3-15 


O 


Object module, 1-1 

Object modules, B-1l 

Object modules, concatenated, 3-3 
ODL, 5-7 

ODL file, defining, 5-15 

ODT SST vector option (ODTV), 3-23 
ODTV, 3-23 
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Operators, 
comma, 5-7, 5-22 
hyphen, 5-7, 5-22 

Operators, tree structure, 

Option line, 2-12 

Options, 2-3 
ABORT, 3-13 
ABSPAT, 3-22 
ACTFIL, 3-15 
allocation, 
ASG, 3-21 
BASE, 3-18 
COMMON, 3-19 
control, 3-13 
device assignment, 3-21 
device specifying, 3-20 
EXTSCT, 3-16 
EXTTSK, 3-17 
FMTBUF, 3-16 
GBLDEF, 3.21 
GBLPAT, 3-22 
identification, 
LIBR, 3-19 
MAXBUF, 3-15 

3-23 


5-22 


3-15 


3-14 


PRI, 3-14 

STACK, 3-17 

storage altering, 3-21 

storage sharing, 3-19 

synchronous trap, 3-23 

TASK, 3-14 

TOP, 3-18 

TSKV, 3-24 

UIC, 3-14 

UNITS, 3-20 
Options and switches, 
Output file, 2-12 
Overlay core image, 5-13 
Overlay description, 5-1 
Overlay description language, 
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5-7, 5-22 
Overlay description switch (MP), 
3-6 


Overlay segments, C-13 

Overlay structure, 1-2, 5-2 

Overlay tree, 5-4 

Overriding switch conditions, 
3-10 


p 


PAR, 3-14 

‘Parentheses, 5-22 
Parentheses, use of, 5-7 
Partition option (PAR), 3-14 
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Path-loading, 6-4 
Pointers, impure area, 
POOL, 3-17 
Pool limit option (POOL), 3-17 
Position independent shareable 
global areas, 7-4 
Position independent switch (PI), 
3-6 
PRI, 3-14 
Priority option (PRI), 3-14 
Privileged switch (PR), 3-7 
Privileged tasks, 4-8 
Program limits, B-17 
Program section, 4-3 
Program section extension option 
(EXTSCT), 3-16 
Program section name, B-6 
Program version identification, 
B-8 
-PSECT directive, 
P-section 
additive displaced relocation, 
B-19 
additive relocation, B-18 
allocation of, 4-5 
descriptor, H-2 
displaced relocation, B-18 
relocation, B-17 
P-sections, 4-3 
P~sections, resolution of, 5-6 
P-sections, sequential allocation 
of, 4-6 


4-2 


5=9 


R 


Read-only SGA, 7-1 
Read/write SGA, 7-1 
Record types, B-1l 
Reduction of virtual memory 
requirements, H-3 
References to shareable global 
areas, 1-1 
Relative disk address, C-ll 
Relocation, 
complex, B-20 
directory, B-10 
global, B-13 
global additive, B-15 
global additive displaced, B-15 
global displaced, B-14 
internal, B-13 
internal displaced, B-14 
p-section, B-17 
p-section additive, B-18 
p-section additive displaced, 
B-19 
p-section displaced, B-18 
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Reserved global symbols, D-l 

Reserved p-section names, D-2 

Reserved symbols, D-1l 

Resident common block option 
(COMMON), 3-19 

Resident library option (LIBR), 
3-19 

Resolution of global symbols, 
4-7, 5-4 

Resolution of p-section, 5-6 

R-O p-sections, 4-3 

R-O task code and data, 4-3 

-ROOT directive, 5-7 

Rules, syntax, 2-11 

Running a collection of routines, 
1-1 

Running a single routine,1l-1 

R/W p-sections, 4-2 

R/W task code and data, 4-2 


S 


Segment, 5-1 
Segment description, 4-15 
Segment descriptor, H-2 
Segment length, C-1ll, C-12 
Segment tables, C-1ll 
Selective search switch (SS), 
3-8 
Sequential allocation of p- 
sections, 4-6 
Sequential switch (SQ), 3-8 
SGA, 7-1 
Shareable global area (SGA), 7-1 
Shareable global area, building 
a, 7-5 
Shareable global areas, position 
independent and absolute, 7-4 
Shareable global areas, references 
to, 1-1 
Short memory allocation file, 
5-16 
Short memory allocation file 
switch (SH), 3-7 
Spool memory allocation file 
switch (SP), 3-7 
STACK, 3-17 
Stack, default, 4-2 
Stack size, 3-17 
Stack size option (STACK), 3-17 
Status, C-1l 
Status word, directive, 4-2 
Storage altering options, 3-21 
ABSPAT, 3-22 
GBLDEF, 3-21 
GBLPAT, 3~22 


Storage sharing options, 
COMMON, 3-19 
LIBR, 3-19 
Structure of memory allocation 
file, 4-12 
Switch (sw), 2-13 
Switch codes, allowable, 3-1 
Switch, default, 2-14 
Switch, overriding, 3-10 
Switches and options, 3-1 
Switches, task builder, 


AB, 3-3 
CC, 3-3 
CP, 3=3 
CR, 3-4 
DA, 3-4 
DS, 3-4 
FP, 3-4 
FX, 3-4 
HD, 3-5 
LB, 3-5 
MP, 3-6 
MU, 3-6 
PI, 3-6 
PR, 3-7 
SH, 3-7 
SP, 3-7 
SQ, 3-8 
SS, 3-8 
TA, 3-8 
TR, 3-8 
XT, 3-9 


Symbol definition, global, 3-21 
Symbol descriptor, H-2 
Symbol directory, global, B-2 
Symbol directory, internal, B-22 
Symbol name, global, B-6 
Symbol table, virtual, H-1l 
Symbols, resolution of global, 
4-7, 5-4 
Synchronous load request, 6-7 
Synchronous trap options, 3-23 
ODTV, 3-23 
TSKV, 3-24 
Syntax rules, 2-11 
System memory, 4-8 


T 


Tables, segment, C-ll 

Tailoring task builder, E-1 
TASK, 3-14 

Task accounting switch (TA), 3-8 
Task accounting work area, C-9 
Task builder data format, B-1l 
Task builder glossary, G-l 


Index-5 


INDEX (Cont.) 


Task builder options, 3-10 
allocation, 3-11, 3-15 
content altering, 3-11 
control, 3-10, 3-13 
device specifying, 3-11 
identification, 3-11, 3-14 
storage altering, 3-21 
storage sharing, 3-ll, 3-19 
synchronous trap, 3-1ll, 3-23 

Task builder switches, 3-2 

Task builder, tailoring, E-l 

Task building, 2-10, 5-16 

Task, building of, 3-25 

Task command line, 2-2, 

Task image, 1-1 

Task image, attribute codes of, 

4-13 

Task image file, 4-9 

Task image file structure, C-1l 

Task header, 4-2 

Task memory, 4-1 

Task, multi-segment, 5-4, 5-6 

Task name option (TASK), 3-14 

Task, privileged, 4-8 

Task R-O root segment, C-10 

Task R/W root segment, C-10 

Task specification, multiple, 2-4 

Task SST vector option (TSKV), 

3-24 

Text editor EDI, 2-9 

Text information, B-9 

TOP, 3-18 

Top address option (TOP), 3-18 

Traceable switch (TR), 3-8 

Transfer address, B-5 

Tree, overlay, 5-4 

Tree structures, multiple, 5-10 

Tree structure operators, 5-22 

TSKV, 3-24 

Type, 2-13 

Type, default, 


2-12 


2-14 
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UFD, 2-13 

UIC, 3-14 

Unable to open workfile, H-4 

UNITS, 3-20 

Use of parentheses, 5-7 

User file directory, 2-13 

User identification code option 
(UIC), 3-14 

Using an existing shareable 
global area, 7-3 

Using parentheses, 5-22 


V 


Version, 2-13 
Version, default, 2-14 
Virtual memory, H-1 
contents, H-1l 
requirements, reduction of, 
H-3 
Virtual symbol table, H-1 
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WSKEXT, H-1 
Workfile I/O error, H-4 
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